We use models to express solution information and knowledge acquired through analysis using a structured set of activities. Agile Modelling is a practice-based methodology consistent with the approach taken by Agile Methodologies for effective Modeling and documentation. Agile Modelling practices are defined based on their values, provide for effective ways to design and model the solution.Â
Agile Modeling is a software development practice that uses the principles and practices of the Agile approach to Software Development. The main idea behind AM is to use models instead of detailed design documents. Models describe requirements and architecture, while developers work on them directly without waiting until all details are known.
Table of Contents
Agile Modelling Values
Agile Modelling values are adopted from and extend Extreme Programming values of Communication, Simplicity, Feedback, Courage, and Humility. The importance of communication refers to the fact that effective communication between stakeholders is essential for the success of modeling efforts. Modeling itself is a tool for communicating understanding about the solution. Communication helps to explore ideas to reach a joint agreement about the requirements and design of the solution to meet those required.
The value of simplicity focuses on keeping the models simple by doing away with unnecessary complexities. It also refers to not focusing on potential long-term needs but focus on precise, immediate needs. In addition, the simple representation of models helps better understanding the ideas.
The value of feedback refers to the need to continue ensuring that your work is correct by obtaining feedback about the models. It incorporates developing models collaboratively as a team, including customers and users, invalidating the models by implementing them so that the developed solutions meet acceptance tests.
Courage‘s value refers to doing the right things, refusing to accept the status quo, and improving the design. Agile requires teamwork, and trust in others and yourself requires courage. It also means that you and others will make mistakes, but you should overcome those mistakes together.
The fifth value of agile Modeling, humility, refers to acknowledging that you will not know everything yourself. You will need help from others to ensure that the solution indeed delivers value to the stakeholders. It also means respecting others you work with, understanding that they will have different priorities, skills, experiences, and viewpoints. Finally, humility enhances collaboration, which results in better outcomes of modeling efforts.
Agile Modelling Practices
Values of agile Modeling were beautifully represented in a diagram by Scott Ambler. These 14 best practices of agile Modeling define ways and guidelines for modeling efforts on agile projects. In addition, these practices provide a way to adopt agile modeling values and core principles in practice.Â
Requirements Envisioning
To get the modeling efforts underway, you must establish an initial idea of the scope of work. The requirements envisioning provides the high-level view of overall requirements to the team and stakeholders. At this stage, the requirements are understood only in enough detail to have a fair idea of the work involved. You will look at the facts about these requirements later.
Architecture Envisioning
It is necessary that a shared, high-level understanding of technical strategy for solution development is developed early on, along with the team and stakeholders, to arrive at effective models. The practice of architectural envisioning is to have a suggestive architectural model, which does not necessarily expose detailed aspects of the technical strategy. Instead, the details of the design are uncovered later through model storming.
Prioritized Requirements
Agile Modeling takes the Just In Time (JIT) approach by modeling immediate requirements first. This approach is possible only with the prioritized requirements. Prioritization enables the most significant ROI for the stakeholders.
Test-Driven Development
The TDD provides a way to think through the requirements and design before you develop the solution. The goal of the TDD is to facilitate the development of code that works. From this perspective, TDD works as the model for solution development.
Executable Specifications
Complementary to TDD, executable specifications provide the team with a functional specification for the development of code. Such specifications, like other artifacts of agile Modeling, are developed by adopting a just-in-time approach.
Active Stakeholder Participation
Active stakeholder involvement enables a Just-In-Time approach by ensuring that information and decisions are promptly available to the team. In addition, project success often depends on stakeholders’ active participation in design and modeling efforts by providing the required expertise to the team.
Single Source Information
The modeling efforts of the team should focus on keeping one piece of information at minimum possible places, ideally at a single location. Everyone can refer to such a location when they need this information. This approach helps in reducing efforts to maintain multiple copies of the same information, enables better traceability, and reduces the risk of inconsistencies.
Document Continuously
The practice of continuously documenting refers to ensuring that agile teams should not treat the documentation as a separate exercise. Still, you should produce all required documentation in parallel to the rest of the solution creation. Thus, the documentation takes place throughout the life cycle. This approach makes sure that all the documentation is in sync with the rest of the solution.
Document Late
The practice of documenting late complements the method of continuous documentation. Agile documentation should be devoid of any speculative content, and hence it should be created just before it is delivered. This approach ensures that the information is stable before you document it.
Iteration Modelling
The beginning of each iteration should involve a modeling exercise, as the models created at this stage would help estimate and schedule the work for the iteration. The iteration modeling is the analysis and design of stories to be implemented during the iteration.
Just Barely Good Enough artifacts
All the modeling effort should be just enough to reflect the task at hand, no more, no less. However, this does not imply low quality or incomplete output, just that it is to be kept lightweight.
Look Ahead Modeling
The detailed Modeling happens with the items of the top priority. However, the practice of look-ahead Modeling defines the need for exploratory Modeling of top-priority requirements. This way, you can understand the complexities of such items early on to reduce overall risk.
Model Storming
You should revisit the models developed during iteration modeling on a Just-In-Time basis to explore the details behind the story or requirement throughout the iteration. Models developed during iteration planning should not be a one-time effort but should be stormed through till the iteration is over.
Multiple Models
With all modeling effort, it needs to be understood that there might be different ways to approach a specific situation. Developing multiple models lets the team compare the strengths and weaknesses of each model and choose the best fit for the problem. Different modeling techniques include UML, BPMN, DFD, Wireframing, and prototyping. Each method has its advantages and disadvantages, and you can choose the suitable ones according to your requirement or preference.
How do you select which model suits best for your project?
It would be best if you considered the following factors:
1) How much time will it take to create this model?
2) What kind of information does this model provide? Is it just an overview, or is more detail required?
3) Does this model help me understand my system better? If yes, then why not try out?
While there is a scope to use any of the many models available, wireframing and prototyping are two popular agile modeling choices on Agile projects. So let’s understand these techniques better.
Wireframes/Prototypes
Closely linked with models, the practice of developing and demonstrating wireframes and prototypes plays an essential role in agile analysis and design efforts.
The idea of prototyping is not new. However, traditionally, prototypes have been used as proofs-of-concept. With agile, there are no separate proofs-of-concept. Instead, the working code itself serves as a proof-of-concept, on which you build the final product iteratively. With agile, the prototypes are more of a mock-up, the visual representations to substantiate architecture design and interfacing requirements. Wireframes provide an effective tool for communicating fast and light and facilitates collaboration across roles and silos by enabling participative design.
Wireframes can be static or interactive. Static wireframes are quick to implement and provide a general idea about the solution characteristics but do not shed any light on interaction. Interactive wireframes, on the other hand, let users explore the experience. In addition, such wireframes help in communicating the behavior of the final product. Therefore, wireframes are essential; they provide an opportunity to work through product goals and information; helps in setting client expectations right; provides a starting point for more detailed design, and allow easier and faster changes cost-effectively.
Finally
Modeling helps us think about our systems before writing code. It also provides a good understanding of how things fit together. However, there’s no substitute for actually building working applications.
