Core and Supplementary principles in Agile modeling

Agile modeling defines a set of practices which can show us the way towards becoming successful Agile modelers. These practices are divided into two sections: “Core Principles” and “Supplementary Principles”. The figure below shows this in a pictorial format:

Figure: Agile model principles

Let’s understand one by one what these principles mean.

Core principles

  • Simplicity: Do not make complex models, keep it simple. When you can explain to your team with a pen and paper, do not complicate it by using modeling tools like Rational Rose. Do not add complexity to show off something. If the developer understands only a flowchart, then explain to him with a flow chart; if he understand pseudo-code then use pseudo-code, and so on. So look at your team to see what they understand and prepare documents accordingly.
  • Welcome change: Requirements grow with time. Users can change requirements as the project moves ahead. In a traditional development cycle, you will always hear the words “freeze the requirement”, this has changed with Agile coming in. In Agile, we welcome changes and this is reflected in the projects.
  • Incrementally change: Nothing can be right at the first place. You can categorize your development with “the most required”, “needed features”, and “luxury features”. In the first phase, try to deliver the “the most required” and then incrementally deliver the other features.
  • Model exists with a purpose: The model should exist for a purpose and not for the sake of just existing. We should know our target audience for whom the model is made. For instance, if you are making a technical document, it’s for developers, a PowerPoint presentation is for the top management, and so on. If the model does not have target audience, then it should not exist. In short, “just deliver enough and not more”.
  • It should be light: Any document or artifact you create should be updated over a period of time. So if you make 10 documents then you should note that as the source code changes, you also need to update those documents. So make it as light as possible. For instance, if your technical document is made of diagrams existing in UML, it becomes important to update all the diagrams over a period of time, which is again a pain. So keep it lightweight, make a simple technical document, and update it when you have logical ends in the project rather than updating it periodically.
  • Keep multiple models: Project issues vary from project to project, and the same project behavior can vary from organization to organization. So do not think that one model can solve all issues, keep yourself flexible and think about multiple models. Depending on the situation, apply the models. For instance, if you are using UML for technical documentation, then every diagram in the UML can reflect the same aspects in different ways. For instance, a class diagram shows the static view of the project while a flowchart shows a dynamic view. So keep yourself flexible by using different diagrams and see which best fits your project or a scenario.
  • Software is the most important thing: The main goal of a software project is to produce high quality software which can be utilized by your end customer in an effective manner. Many projects end up with bulky documents and management artifacts. Documentation is for the software and not software for the documentation. So any document or activity which does not add value to the project should be questioned and validated.
  • Get rapid and regular feedback: Software is finally made for the user. So try to get feedback on a regular basis from the end user. Do not work in isolation, involve the end user. Work closely with the end customer, get feedback, analyze requirements, and try to meet their needs.

Supplementary principles

  • Content is important than presentation: The look and feel is not important, rather the content or the message to be delivered by the content is important. For instance, you can represent the project architecture using complex UML diagrams, a simple flow chart, or by using simple text. It will look fancy that you can draw complex UML diagrams but if the end developer does not understand the UML, then it ends no where. A simple textual explanation could have met the requirement for communicating your architecture to the developer / programmer.
  • Honest and open communication: Take suggestions, be honest, and keep your mind open to new models. Be frank with the top management if your project is behind schedule. An open and free environment in a project keeps resources motivated and the project healthy.
Tagged , . Bookmark the permalink.

Leave a Reply