Cont: Where does the Ubiquitous Language come from?
This is a follow up post to a question Scott Bellware asked me concerning origins of the Ubiquitous Language. To save you time with having to go back an forth between the post this was my response.
“We practice a hybrid approach to the planning phase which introduces another layer above the story. Cohn refers to this as an epic; we have elected to use the term Feature.
The interesting aspect to all this is that the product owner(s), in our case 8 Business analyst all ask for varying features some even overlap at times. The modeling teams which consist of a one BA, Modeler(developer), Developer, and QA all get together to model the feature from a high level. It is a wonderful exercise as the team practices DDD modeling with everyone involved. Spoken and written ideas form a HIGH LEVEL domain model. Don’t confuse our modeling with UML.
So we have a feature originating ubiquitous constructs a model that then refines those constructs into additional stories that can be prioritized in a backlog. All the while cultivating the “ubiquitous language”. At the end of the day the developers all get together and present their models to the development team. We distill the models to insure that other modeling teams are not coming up with the same ubiquitous terms and refine/clarify if needed. If their are any major changes we reengage the business with QA.
Why did I give everyone all this detail. Because “it depends” on how your process originates terms that form the ubiquitous language. Even though the terms may have existed far beyond any developer showing up, the terms are galvanized when people talks towards them in the hope of producing better software.”
And Scott Responded with:
“Good points, Joe.
My follow-up observation then is to your specific process. Or rather, it’s a question (or two):
What are the benefits to eschewing story practices as the initiation of the process and going with agile modeling?”
This is a very good question that Scott has asked but you need to know some background before I answer it.
Background
Our team started with XP around 4 years ago. At first there was allot of resistance towards Agile in general. It was too esoteric in nature for anyone to even trust or try. Everyone was frustrated Developers, Business Analyst and Systems Analyst all where ready to give up. There were several attempts to return to a traditional methodology but several members of the team stood fast and helped the department at least TRY Agile.
As the team moved forward with developing systems for the business they learned to embrace Story cards but only to a certain extant. Design documents were still drafted and accompanied the story cards. This is a very bad thing! Once a design document appears it is gospel and dialog ceases to flow. It become very one sided and the discussion flows like this, “Make it work this way!” The birth of entropy! Time passed and we were able to convince them to discuss the stories with us prior to looking at design document. There was a dialog that was forming but it wasn’t ubiquitous. In fact we discovered that even amongst the domain experts they had several terms for the same artifact! Half of the country would call it one term while the other would call it another. Another aspect that was suffering were acceptance tests. The quality group didn’t have enough information gathered during the planning sessions to write effective acceptance test. We were practicing Agile but we were just getting by. Sure we were creating working software every 6 weeks and quality was at an all time high but understanding of the Domain outside of the business and amongst the business was slowing deteriorating. The system was getting so large that the business was stepping on each other.
At this point our solution was at about 300K lines of code and approximately 2500 unit tests. Pretty large. What happened next is what really tested our team and Agile.
We were given a new project that would extend and double the functionality of the current system. To make things worse this project was date driven! We only had 9 months to complete it. Based on the enormity of the project the team size practically tripled over night. We had 12 business analyst 3 of which were remote. We had a team of 7 quality technicians and 16 developers!
Don’t forget we still had existing communication issues with what we were doing and this new effort only compounded that. We had to do something to streamline the communication and cultivate the design of the new system. Enter Domain Driven Design.
We decided that if we were going to do this we needed a mechanism to flush the domain concepts out on the table and put the issues out there for everyone to see but we had to make sure it happened BEFORE we touched the code. Having read Domain Driven Design twice by this point, I decided to train not only the development team but the business and quality group as well on the activities. What happened next was simply amazing!
Storming
Before a release the team gets together with the business to discuss what “Features” the business is desiring. After the business gives us a summary of the functionality we give each Feature a weight of High, Medium or Low. What this signifies is an approximation of how long it will take to model each feature. A “high” is 8 hours, a “medium” is 4 hours and a “low” is 2 hours.
So what is a modeling session?
A modeling session consist of a Business Domain Expert, a developer , QA, and a developer who has the soft skills to lead a modeling session, we call this developer “the modeler.”
It begins by asking the Domain Expert to talk about the features, establishing the bounded context. During the discussion the modeler is diagramming the model with colored note cards. Entities are green, Value Objects are yellow, services blue etc. The white cards typically notates the usage stereotypes of the model. During the discussion the group pays special attention to insure that the ubiquitous terms are being used. Because the dialog now has a tangible pictorial representation the team talks towards the model. Anyone can add a new Entity or change a behavior to help cultivate the “ubiquitous language”. Problematic business cases immediately come to fruition and are dealt with outside of writing code but not done in a vacuum as traditional UML is practiced today. The team has to pay additional focus in insuring that the modeling session stays within the features context. If there are any artifacts that spill outside of the context that are put in a parking lot box and reprioritized for later modeling sessions.
At the completion of the session the Modeler distills the model with the team into smaller stories that can exist on their own and deliver part of the feature. It is important that as the Stories are being created that the QA representative examine the model to look for all the acceptance test that are going to be needed to call this story done. If the QA representative can not figure out how to test it then it isn’t a story!
What makes things complicated is that we have at any given point in time 4-5 modeling sessions happening concurrently. So what happens at the end of the day.
At the end of the day the modelers(developers) get together and compare their models. They go through them to find any duplicate concepts or issues that may arise as a result of blending certain models together. They take great care in using “Ubiquitous” terminology in expressing their models with one another. If an issue arises then both teams reengage (Dev, QA, BA) to figure out a solution. Usually it take a short time to refine both models so they play nice with one another. The awesome part is that everyone learns! The business understands their system much better and the developers have a greater understanding of what they are building as well.
Now that we have all the stories defined for the release, the traditional planning game commences with SWAGS being given for how many points it is going to take to finish each story. A give and take occurs between the business and development team but the business has a better picture of how the “nice to have stories” fit in with the “must have stories” due to the modeling exercise.
So how long is this modeling/planning phase? Approximately a week. Releases look like this typically.
- Storming Phase (1 Day)
- Modeling/Planning Phase (Approximately a week)
- Iteration A (One week long)
- Iteration B (One week long)
- Iteration C (One week long)
- SIT (One week long)
- UAT/Production (One week long)
What do you do with the models after a release? If you ask me this at work, I am going to tell you that we archive them for future reference and review them periodically to insure that are integrally sound. Outside of work. The are put in a file cabinet or on a shelf and we rarely go back to them. Usually if we have a new similar feature arise we model again to insure that “time” has not changed it intention or value.
Why the hell did you give us so much detail to answer this question?
“What are the benefits to eschewing story practices as the initiation of the process and going with agile modeling?”
Because (drum role) it depends! If you have a small shop and one to two domain experts on site then modeling may be over kill. Story cards should be all that you need to issue in discussion about the domain and still come up with a great design and a “ubiquitous language”. I gave you this detail to show you the evolution of the evaluation of circumstances that resulted in a domain modeling solution. As Agile practitioners you must think outside the box. Not one practice or methodology may make sense but don’t blame the methodology or the practice. Remember that “Agile” is an adjective not a noun. Be agile when you approach any software development issue. Use Agile development methodologies and proven agile software engineering practices as a chest of tools that help you to get your job done. Above all never be dogmatic, be agile.