home | agility | comics | kids' books | about

Personal Opinion: Why XP and AMDD?

Beginning in 2003, I became quite fond of the Agile Modeling (AM; agilemodeling.com) Values, Practices and Principles. Similarly I have also grown fond of Extreme Programming (XP; extremeprogramming.org).

Furthermore, what makes me even more confident about these methodologies is the plain and simple fact, that I have yet to hear anything bad about these methodologies from any developer that has actually worked with it – I'm talking about some very intelligent people that are either working with these two methods or promoting one or both.

AM is about modeling and documentation in an effective manner using simple tools. XP, on the other hand, is a full development lifecycle. Both of these align very well my views on software development; views that are based on experience I have gained over my jam-packed twenty years in IT working for a dozen or more very large, and also small, companies.

Prior to AM and XP, I had worked with the Rational Unified Process (RUP) and before that some custom home-grown methodologies. Even though I enjoyed using RUP for a while, I began to find RUP a bit on the heavier side when it came to requirements documentation, up front architecture and design; at least this is how I see most organizations using RUP. On the other hand, Agile Modeling and XP are nimble methods!
It takes a bit of time to get the hang of it, some of this is due to internal resistance to change or misconceptions about XP. However, once you do get it, boy does it feel good! It feels so natural that you have to sit there and wonder why it took so long. Seriously, these two methods are getting more and more popular by the day because they feel so natural to developers.

Another reason XP and AMDD might take a little getting used to is because these methods don't work in a linear fashion. This is the case because things don't always work in a linear fashion in the real world. Also, this approach facilitates change better than the rigid linear methodologies where all the requirements must be locked down up front and the customers have their hands slapped if they request too many changes. Change is inevitable, so it is better to deal with it by embracing it. Trust me, it took me a little getting used to because I had been working in the linear/rigid mode for years before discovering XP.

Incidentally, the term Agile refers to the wide range of software development methodologies since Agile highly compliments methods such as RUP, XP, Scrum, Feature Driven Development (FDD), Crystal, and so on. This is exactly what I like about Agile and AM. It is a one-stop website for me for getting a wealth of knowledge at the tip of my fingers.

Agile Model Driven Development (AMDD) is more specific to development. I chose AMDD for this book because in addition to the fact that the AM viewpoint aligns with my own, I also like that AMDD proposes just good enough modeling artifacts (such as, free form architecture diagrams -- my favorite kind). Perhaps, these words from the AM website best summarize my feelings about producing artifacts, "your goal is to build a shared understanding, it isn’t to write detailed documentation". Need I say more?

On the XP side, you will find many of concepts used in this chapter and throughout the book; concepts such as user stories, CRC cards, test-first design, release and iteration planning, and more.
I have already stated reasons why these are popular with developers. However, customers love this style of working too since both these methods are customer focused and require active stakeholder participation. Granted this does require more of the customer's time but they are pleased to see constant progress and as a result less things can go wrong with a project since there is ongoing communication between the customer and the developers.

Ongoing communication with the customer also helps the developers stay focused on the end goal and understand the problem domain better and faster. Hence, understanding the customer's problem or need, and staying focused on it throughout the software lifecycle is essential. By having ongoing communication and easy access to the customer, this task becomes a lot easier.
Let me summarize why this makes so much sense by providing you the end-to-end process using XP. Your team builds and unit tests software daily, the application is integrated often (maybe even continuously as unit tested code is checked in), a production-ready version of the application is deployed every two weeks (iteration), and the customer gets to test drive or fully use the newly added functionality, every two weeks (with a full release every two months).

All in all, it is a win-win situation for all project stakeholders!