In the second chapter of his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, John Stenbeck introduces agile project management, including the different frameworks that exist in the agile world and some tools which can be used independently in conjunction with any of these frameworks. Yesterday’s post covered Test Driven Development (TDD), and today’s post covers the second example of an agile project management tool known as Agile Modeling (AM).
Like TDD, Agile Modeling (AM) can be used in conjunction with other agile frameworks. Its most common usages are for software development projects.
Here are the basic principles behind Agile Modeling (AM).
- Create multiple models in small increments–this is because any given model is bound to include some inaccuracies, and having multiple models will more likely produce code that ends up actually working
- Create an abstract representation of the software–then prove or disprove its performance with code that either works or does not work
- Use the right artifacts from each model–team improves its understanding of the approach to the solution
- Follow a continuous forward match–iterating to the next model after one model is verified
- Get active stakeholder participation in AM–project stakeholders know what the result of a successful model will be and can provide crucial feedback needed to improve between each model
- Use applied simplicity–focus on the practice of only creating models for the current facet of the problem; this goes hand in hand with principle 1 above of creating multiple models in small increments, avoiding large, detailed models. Do just enough modeling to understand the scope of the problem and the architecture of possible solutions.
- Use open communication–display models on walls or Wiki’s, embrace collective ownership of artifacts, and use group-based model development.
These principles allow a team to do modeling in such a way that possible solutions are suggested, tested, and then improved upon in subsequent development iterations.
This concludes the two posts on agile project management tools. Although they were developed for software development, it would be interesting to see if they can be applied to other application areas, in the same way as agile project management methodology is beginning to be applied on a wider basis.
The next post will be a wrap-up, where I give my I give my “agile beginner” impression of the various frameworks and tools, speculate on why they enjoy the market share that they do today, and what the future holds for them in the world of agile PM.