Blog

Disciplined Agile or the Development Framework was originally developed by IBM. Then it was transferred to an independent consortium and now is part of the PMI family. Developed from agile reality (and not theory).With the introduction of agile methods, we experience “exciting” new things, some even more exciting than others – and some being exciting but not in a very positive sense. There are many reasons for this, and everyone probably has their own story to tell. It depends on the situation - maybe I manage a pure IT development project or a project that has an IT development component (as one of several parts) – which is usually the case with me, or I am dealing with the Development of an organization towards "agility". Disciplined Agile does not take a descriptive approach that requires painting process diagrams on a wall that sometimes differ considerably from reality. Instead, it is based on practice where somethings run differently from the documented processes and are constrained by practical limitations. In which case one may consciously want to have a choice as to how to proceed. It also contains elements that are often not considered, such as risk management. Keywords such as "restrictions and dependencies" exist, one way or another. Disciplined  Agile does not make them disappear in real life or even just from the field of view (by the way, something that I have experienced time and again in projects with agile development) but creates an understanding of these limitations and provides structures for dealing with them while remaining as agile as possible. In other words: Disciplined Agile does not simply “dumb down” something compelx. It help you manage complexity. More than development.In Disciplined Agile, the development lifecycle consists of three phases, with each phase aimed at achieving specific goals. The Inceptionphase is to set up the organization and the team, the scope, releases, the test strategy as well as looking at the environment, such as the corporate orientation, strategy and architecture. The business requirements and non-functional including quality requirements as these may impact product acceptance, are clearly defined. The Construction Phase is to build the product with a focus on "IT-architectural stability" to ensure quality "consumable solution" (in clear contrast to "working software") is delivered. Of course, especially at this stage, the numerous known methods of agile development that we know and work well are in use. The third and final phase is the Transitionthat ensures that the solution truly and holistically includes what is needed to be delivered. These three phases complement those viewing elements that are rather absent from a pure development methodology, e.g. SCRUM (the method of agile development that is primarily used). The focus is always on the final goals and the result – not on the immediate next step. Incidentally, Disciplined Agile does not only provide for a single lifecycle type, but several. In this way, one can choose the procedure that best fits a particular situation, depending on whether there are exploratory elements and to what extent changes are expected. Critical minds might now say: Well, this is a hybrid approach where an agile method is in a "sandwich of prediction". Hybrid certainly, yes. However, Inception and transition do not have to be particularly long or even exist. This depends on how far and mature the teams and the organization are. At some point, the only outstanding phase for current deliveries and with appropriate lean design (also in the sense of a continuous further development) is the development (Construction). During operation, the topic of DevOps is considered. Disciplined Agile includes Disciplined DevOps and thus an integrated view of development and operation is in a constantly evolving cycle. Working Software: No. Consumable Solution: Yes.The idea of an incremental development is of course nice, especially with fixed times and reasonably fixed resources. In an end-2-end view, however, many increments may be functional on their own, but the overall solution is not acceptable. Difficulties may be experienced in the design of the system architecture and the simultaneous development of the software and dependencies on other systems and processes. The last step of an integrated view of the system is sometimes accompanied by conflicts or at least friction losses. With Disciplined Agile there is room and structure for dealing with these. Scaling please.I keep hearing the notion of scaling, which I think it is used for different things. Disciplined  Agile takes up the topic in two ways: One time it is about scaling from the pure development level (I like to talk about the "development process") to the project or program level. The other is scaling throughout the organization. This makes it clear that Disciplined Agile is interesting and relevant to different groups of people. I recommend existing SCRUM Masters, project managers from IT as well as people from the PMO, should take a closer look at the topic. What do I like best about Disciplined Agile?

• Let complex things stay complex.Development projects and more specifically the environment in which they exist, e.g. they are part of a larger program or an organization, the market, etc. all give rise to complex situations. Instead of trying to simplify things by hiding things, I like to have structures to navigate through and deal with these complexities.
• Think holistically.Development is often part of something bigger. Be it the development itself (e.g. as part of a program), in the organization, in the system environment, in the processes and of course from the customer's point of view (keyword End2End consideration). Looking at these things is a harder to do, but it pays off.
• Integrated. What is in Disciplined Agile is very much what my stomach and head feel from the beginning of the "agile boom". The integrative approach also enables the establishment of links with other disciplines, fields of knowledge, frameworks and standards of project management.

  And that's just the beginning. Since Disciplined Agile has become part of the PMI family, it is obvious what will happen next; existing knowledge will continue to be shared, integrated and multiplied. This is how we ensure that we constantly drive new things that work well in our projects (and in our lives).