You might be hearing recently about a new thing called disciplined agile. It’s a PMI Product, and you might be wondering what it is? Usually, if it is an Agile way of working, with the agile approach, it might be some framework that helps us get things done faster, but incidentally, the discipline agile is not a framework; it’s a tool kit now. You may wonder how it is? Because ultimately, we need some structure for completing our work and most agile approaches, be it Scrum or Kanban. Agile positions itself as a framework, so what is a framework? In a way, the framework gives you a structure; you can decorate that and add your things as and when needed.
Some of the frameworks have predefined, well firm boundaries given to you, and you have some flexibility, some ideas, which you can add to while some are very lightly defined. They might be giving you a kind of skeleton. Then you can decorate and work with it. So the discipline agile is coming up with an approach that you know, be it a light framework or a heavy framework, it’s still a framework that gives you a good starting point. But it also limits you from doing something that might be appropriate for you because you may have multiple teams, multiple business organizations, and each team. Each organization may have different contexts. Putting them into one boundary, a common, may not be a wise idea. Their context may be different. Now somebody will say, what is the context? We know that some of the development might be happening in a project mode while some might be in a product mode. Some of the stories might involve multiple vendors, teams, some of the development might be happening through the geographically distributed team. Now since there is a variation, they may require different ways of working. The team should evolve their way of working on their own, so what is discipline agile, and how they help us find out our ways of working, so in a way, we can say that Discipline Agile is giving us the building blocks. Some significant building blocks help us create more extensive Structures, and some minor building blocks help us get things done. Regularly, one of the overall building blocks is a life cycle you know you have to choose.
A life cycle, rather than giving you one option, provides you multiple lifecycle options. For example, if you think of a new product’s a very vague idea, you want to run a lean startup, a cycle that particular initiative may run under an exploratory life cycle. You may have another product that might be in a continuous delivery mode because it is running for the last six months. It can have a constant delivery lifecycle. You may have some initiatives that are well defined. Now you understand the customer persona and the business problem you are trying to solve. The requirements are still emerging; you may work on the delivery life cycle for that particular thing. Hence, the discipline of agile gives you multiple life cycle choices, and I feel this life cycle is like an outer layer that you can choose. As you progress from one way of one type of problem to a different kind of problem, you can also change in the same product domain.
Once this life cycle is clear, we usually know the framework, roles, ceremonies, and artifacts. And somebody may wonder, what happens to these three when we use discipline agile. So when it comes to the role, they give you primary roles and many secondary roles or add-on roles. The primary roles are something that needs to be there as you get started. So a small team, big team, or any team have those disciplined agile primary roles. But as your context emerges, sometimes you need a domain expert, sometimes you need a program manager, sometimes you need a special architecture, a domain expert. So additionally, as your context evolves, you can add these supporting roles to the flexibility and how they put it in a toolkit mode.
So finally, talking about events and artifacts, so in DA case, the events and artifacts are also choosable. So what they do is they talk about a goal-oriented approach. They have process goals, and to achieve a process goal, you can do various things; for example, you have a process goal of coordinating activities among the development team member or the team members. You can achieve this process goal by doing a daily scrum daily to inspect and adapt meeting. You can also accomplish this process goal of coordination work among different team members by having electronic chat channels and tools that help you collaborate. The idea here is not to do a 15 minutes meeting or not to use a particular chat tool. But to have a common understanding related to your work and your activities. So you have a goal, and these process goals are in the DA toolkit. Each process goal has multiple decision points. There are various options and various considerations documented in discipline agile, which helps us as a team member, as a coach, to find out which way of coordinating will be suitable for me because the context varies. You know, one team could be geographically distributed or co-located, so we need to have different ways of working for those two. So the artifacts and events are also selectable.
So that would be a prime word to say you can decide based on your context, so you have a life cycle that gives you the upper framework. You have roles that are primary and secondary, and you are goal-oriented.
The approach will let you identify what kind of events, what kind of
artifacts might be helpful for you to do your development job if you want to know more about discipline Agile and visit the PMI website. If you’re working in an agile coaching, agile consulting space, especially in a diverse background space, I believe you may get a lot of value by
studying discipline agile.