Check the depth of the pool

I was really inspired by Jimmy Bogards latest post. I find that taking the simplest path does not always lead a team down the most best path that towards sustainable flow (continuity).

I am a huge proponent of Agile Modeling. Agile Modeling coupled with Domain Driven Design provides a mechanism that can galvanize a team towards malleable code that enables evolutionary design.

When I coach on this practice people cringe at the thought of modeling as previous attempts have led towards heavy weight processes.  What I am proposing is before you dive into the pool at least check the depth of the water to see if you are going to crack your skull when dive in. Just because we are practicing Agile development does not mean it is OK to be careless.

Start simple

State the problem you are solving for.  The problem should be Feature driven as through the modeling exercise you should arrive at several stories.  You are solving towards the problem indicated on the feature card not towards the application or project. This provides a context that will help guide discussions.

_Check how cold the water is_
Take out several index cards and at the domain level just perform a simple Class Responsibility Collaboration (CRC) exercise. http://www.agilemodeling.com/artifacts/crcModel.htm  CRC diagramming has been around for over 2 decades and is one of the most over looked practices of software development. It is simple, highly communicative and provides immediate value for the entire team.

Please DO NOT try to create your entire solution is one diagramming session. Remember you are talking towards the feature.

_Check the depth of the pool_

Just like when you prepare to dive into the pool you quickly survey the depth markers on the outside of the pool and determine where the deepest part of the pool is. You then perform a quick calculation in your head. “I am