Hi, welcome to this lesson where we will briefly review the methods and frameworks we have discussed so far and then decide which of them we will explore in more depth in the follow-up courses as part of a simulated project flow.

In the last lessons, we have seen how the project and process management methods considered together harmonize with each other – and can also be used in combination in practice.

Let’s recap the combination all over again:

What is the milestone trend analysis used for?

In the practice of software development we find the milestone trend analysis in any case in the release planning, in which from the release date the temporal planning

• of the exit gateway,
• the build freeze,
• the code freeze,
• the release train,
• the product increments
• and the sprints within are made.

The release train engineer needs a constantly updated graphical overview of whether all teams are on schedule with their sprint content and the subsequent tests, as well as the build and deploy process, in order to be able to take corrective action in good time if things drift apart.

However, we also find milestones in portfolio-driven projects, where management reviews the progress of the project at fixed milestones in order to update the cost-benefit calculation or, if necessary, to adapt the project to conditions that have changed in the meantime. So we need and is packed in our shopping basket.

Where is the waterfall method used?

After all, we would like to avoid the waterfall method as much as possible because of the disadvantages we have discussed. We want to be flexible and achieve usable results quickly. This speed has only one disadvantage: if the data model of a new software solution is also constantly revised and adapted, then the majority of the work based on it must also be done or adapted over and over again. The more advanced a project is, the more complex and expensive this constant new start becomes. In order to avoid this inefficiency, it has become common practice to invest a little more planning effort in the definition of the data model and to actually apply a waterfall-typical approach here with a rough concept, detailed concept and IT concept based on a prior determination of requirements. The demarcation from the complete waterfall model here is the type of requirements elicitation that is limited exclusively to the strategic goals and the development of a basic model and does not address the detailed requirements from the business units. The data model developed in the process is basically agreed with the department heads and relatively fixed for further use. Everyone involved is aware that a subsequent change to the data model causes a considerable amount of additional work, which easily exceeds a project budget and schedule. Of course, a data model is extended in the course of a project, and also afterwards in the course of the further development of the software – but please always without major reconstruction work of the basis, which would subsequently make an inventory data migration necessary. This is because it is always very time-consuming, thus expensive, a great risk for bugs and thus fraught with risks for the data stock and the further use of the software solution. So it really makes sense to develop the data model with a little more planning effort and thus provide a well-prepared basis that has been clarified with the customer and can be used by the developers. So we also need and is thus packed into our shopping basket.

Do we need agile project management?

Agile project management is a must anyway, because we want to achieve usable results flexibly, efficiently and quickly. Of course, we could now say that the decision whether agile or through-planned could be debated. And there are also different opinions and good arguments for both sides. In the field of software development, the advantages of agile, as already discussed in the preliminary lessons, simply weigh very heavily – and that is why I refrain from discussing it at this point. Agile project management is therefore also added to the shopping basket.

What is the Kanban method used for?

Task tracking with Kanban boards is so widespread in large companies that we can’t do without this method either – and I personally wouldn’t want to do without it either. The advantages of this pull concept are too great for me, including the transfer of tasks to other teams and real-time monitoring by management. So also lands in our shopping basket.

Why is Scrum practiced?

Scrum, the naked Scrum, hardcore – yes, there is indeed an excellent argument about that. And I am therefore dedicating an extra lesson to this topic. But we can hardly do without it in software development, because the method provides us with a whole range of suitable tools and events. And it is not without reason that it is by far the most used method in software development. Disconnecting from this would mean that collaboration with other development teams would no longer be smooth, nor would it be possible to integrate new team members into the process as quickly. We would also forego the consistent exposure of weaknesses and errors, which would nevertheless greatly weaken and set back a project. We would no longer be truly competitive without Scrum. So Scrum is also added to the shopping basket.

What is the Scaled Agile Framework (SAFe) used for?

SAFe extends agile project management with Scrum and Kanban from the team level to the structures of a large company. SAFe adopts the elements of Scrum as well as Kanban. And since we are dealing with large-scale projects in large companies here, we also need this building block in our shopping basket without too many words.

What is Lean Management used for?

Oh what great projects we all know, where excellent technical solutions have been developed – but unfortunately at an expense and therefore price that can never ever become profitable. These self-purposes and hobbies must be avoided by comparing every expense with an economic consideration and constantly reviewing existing processes for optimization potential. Only this makes us competitive in the project and thus also profitable. And because there is no project without money, we also put lean management in the shopping basket.

What is Six Sigma used for?

The second lever for profitability is error and quality management. This is what Six Sigma deals with. We can’t get around Six Sigma in large companies anyway because of its high prevalence. The method is, so to speak, compulsory to accept, so we also pack them, albeit somewhat reluctantly, in our shopping basket.

Which methods and frameworks are used for projects in large companies?

What a miracle, we actually wrapped up all the methods and frameworks covered. Well, it’s not necessarily a miracle. These are the main ingredients for a successful software project in large enterprises. We didn’t waste valuable time with this in the previous lessons either. Other methods and frameworks already exist, and would certainly have been interesting. But also a waste of time in a course series that is already very extensive.

Is there one perfect method for projects in large companies?

At the beginning of the course I referred to an experience, how the supporters of their preferred method sometimes have speech and argumentation duels about whose method offers the best solution – which of course always has to be adhered to 100%. I, on the other hand, present you with a mix of everything and would like to show you how we use the best of everything in the appropriate place. And this is only possible if you (please forgive me this expression) are not only a specialist idiot for a limited subarea. What good is an isolated Scrum specialist, or a Kanban specialist, or a Waterfall specialist, or a Lean specialist, or a Six Sigma specialist? Isolated, they offer me answers only for parts of specific situations. But if I pack them all together, it is not only very expensive, but also eats up my time unnecessarily, because they get lost in discussions about which approach would be the most suitable for this situation. And then I still do not have a solution. Experience then beats any theory here, or uses the theories in the current context. This requires a certain basic knowledge of all possible methods. And we have basically learned about those in the last lessons.

Now let’s summarize what we have covered in this lesson:

• we have taken another rough look at all the methods and frameworks discussed so far,
• and then considered whether we need them in the course of a major project in large companies.
• We eventually wrapped up all the methods and frameworks covered, noting that we didn’t waste any time in the previous lessons.
• I hope to be able to convince with my attitude that projects are always individual and therefore the individually suitable combination of the discussed methods and frameworks influences the project success significantly.
• We are aware that we like some methods and want them badly, need some and cannot do without at least one because we cannot get around it in the large enterprise environment.

In the following lesson, I would like to cover the pros and cons of Scrum – especially naked hardcore Scrum – and the associated likes and dislikes among team members. See you in a moment.