Throughout the life of project there are many potential pitfalls to implementing and practicing agile. As the agile principles and values are put into practice it’s important to take steps that keep the path of agile best practices for which you are looking to benefit from. The use of Agile Modeling is an excellent way to integrate agile principles and values that can complement almost any other agile methodology (i.e. Scrum, XP, etc.).
Agile Modeling components don’t all need to be implemented to make your project agile, however the more you can put in place with thought and importance in each project situation, can provide solid benefits over time. Most importantly, they provide a good framework to building an agile mindset, and integrate seamlessly in an ongoing agile project. The following is a short list of some components:
1 – Active Stakeholder Participation
As with any agile project, the best way to guarantee success is to make sure your stakeholders are involved at all times. The Product Owner usually is the voice of the stakeholders, and we would all hope that it is always that one person that could speak for many. The importance of “Active” is the key to success. There can be times where stakeholders come out from hiding and suddenly become a decisive voice (make or break) in the success of a project. Late stakeholders that become active at the end of a project open big risks as it is the most costly point at which to make changes to accommodate their expectations.
2 – Document Continuously and/or Document Late
Notice here that we mentioned “and/or,” as an approach to documenting your deliverables. It likely will depend on the type of solution and dependencies of functionalities between features as deliverables. That is to say, it’s always best to document continuously so that you don’t have to wait until the last-minute to remember which features were implemented in your solution. As expected in an agile iterative nature, you are looking to deliver a potentially shippable solution at the end of each sprint. This would require regular documentation revisions if the features were to change and evolve drastically over the course of numerous sprints.
Admittedly it sounds contradictory, but this is where it would be best to document late, since it would be less wasteful if you were to document your deliverable once all features were integrated as much as possible. Particular attention needs to be placed on the nature of the product and development. As in the case of software development, releases occur frequently, some major and some minor. Some consideration as to what will be major and minor can allow for less waste when it comes to documenting.
3 – Iteration Modeling
As the initial part of any iteration, we expect take some time for planning. Usually that time will vary from a half day to an entire day depending on the duration of your iteration/sprint. Iteration Modeling outlines the features and design of what is expected to be delivered by the end of the sprint. Some features may end up being developed in sub-parts over a number of sprints, as well as entire parts. The importance here, is to outline how modular some features may be to the rest of them. With that in place, it becomes much easier to prioritize a sprint backlog, which brings us to the next point.
4 – Prioritized Requirements
There are many factors that go into prioritizing requirements, but the one starting point to attaining this is to actually have a backlog (or list of work items) in the first place. In most cases this Sprint Backlog will come from a much larger list called the Product Backlog. As many practitioners soon find out, prioritizing is a key activity that requires identification of numerous factors such as: ROI, risks, stakeholder needs, functional dependencies, available resources, etc.
5 – Single Source Information
If there is one thing that can cause duplication is a highly bureaucratic and disorganized framework from which an organization is set up. Although seemingly simple, having one single source of information is a major challenge for an organization. Many will point to 1 wiki page as a source of information, whereas other departments try to set their own identities and create their own versions of information that gives them a sense of purpose. From an agile project approach, it is extremely important that all parties learn to use one source of information so that it is updated in 1 location to reduce redundancy and waste.
Many companies today, still strive to revise documents of the same content, but in different locations every time there’s update. Beyond just the internal operations, the complexity of multiple sources increases when working on a project where the client looks to use their own sources of project information in conjunction with that of the vendor’s information. In this scenario, duplication is not efficient and is highly wasteful throughout all organizations, as everyone struggles to find out which is the latest version of the code, documentation, template, etc.
More Agile Modeling Guidelines
From an Agile Modeling perspective there are many more components that make up the framework of agile best practices. The important factor to consider is that it will not be an overnight implementation, nor will it be an overnight success. It takes a considerable amount of time and resources to make an agile system work, but unfortunately, not many want to invest, and expect instant gratification. As history will show, even the concept of instant plug-and-play came with a series of bugs and fixes.
[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]
Share this:
This work is licensed under a Creative Commons Attribution 4.0 International License.
