Q
Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

For Agile development teams, can in-depth discussions replace design specs?

In-depth design discussions work for Agile development teams, replacing the creation of design specifications.

Application design discussions can replace design specification documents and, depending on the quality of an Agile...

development team's communication, are more effective in delivering high-quality code.

Because Agile design is ongoing, design discussions are literally the most important discussion that Agile development teams have daily. Developers and architects need to think through the design, hash out style and other differences, and come to agreement. It's not necessarily a formal meeting, although design discussions can be any format -- such as a meeting or just an unofficial discussion with a white board. Design discussions need to occur whenever the team reaches a discussion point or an Agile development team member poses a question about the current design.

Design discussions occur before any business code is written. Test the prototype code and prove the design by testing it. Use test-driven development TDD principles to determine the strength of the design. Flush out any concerns or issues before writing the code. Proof-of-design credibility creates fewer surprises down the road.

Design happens in the first few days or week of a project. By the end of that first week, the testing team understands the code, making their test more valid because they are better able to test for failure points. Application quality improves.

The more that design discussion occurs up front, the more developers agree and code is written as agreed to. There's less cowboy coding or abandoned code, which also increases application quality. An Agile development team could be through all of this before a specification document is written, read, discussed and, ultimately, ignored.

The key to quality is communication and continuous design. It's imperative to include customers and product management in design meetings as much as possible. If not, the product manager must read, review and understand the design concept and verify that the end business goal is met.

For my money, design discussions are valuable for both the short and long term, and are more useful and relevant to delivering the right code to the customer with the highest possible application quality.

Next Steps

Making Agile development fit for business

Keep your software healthy during Agile development

This was last published in July 2015

Dig Deeper on Agile Software Development (Agile, Scrum, Extreme)

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Join the conversation

12 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Do you think in-depth design discussions can replace design specs?
Cancel
We haven't done a design specification in years. I don't miss them, but sometimes I feel like we've veered a little too far in the opposite direction. Once, the entirety of our product design took place as a conversation between two dev managers, in a car, with some minimal diagramming on a scrap piece of paper. That project did not go well. There were too many holes, and constant discussions about the design among the rest of the team members who didn't really understand the design because they weren't present for the discussion, and there was no documentation. So I believe that there needs to be a balance.
Cancel
Rather than having formal in-depth design discussions, wouldn't it be appropriate for the stakeholders to get into a conference room for one whole day (even days sometimes) to discuss the design nuances using lean tools like mindmaps, flowcharts, UI prototypes (even paper prototypes), textual requirements, etc. followed by technical stakeholders gathering technical inputs like what kind of information, what business logic, what objectives are we trying to achieve beforehand? 

Plethora of tools out there have enablers to capture the requirements, which will then need to be circulated across and then people can debate on the functional requirements. Technical stakeholders can possibly search for efficient ways to capture and present the data across the incumbent application being developed during the due course. 

In a nutshell, we all strongly believe that the development process is ever evolving and we cannot just consider a day's discussion as final. However, the initial design discussions and bringing all the stakeholders under one roof will surely add to the long term objective of any given project/product's goals. 

Please note that the aforementioned has been my experience working with products and projects. Some stakeholders might believe that it might be a complete waste of time and resources. But, how can one be more efficient in wanting to represent a 1+1 = 11 rather than just 2...if am making any sense at all. 
Cancel
You are both making sense. I think it has to be a balance, for sure. Have you found the culture supportive to the idea of discussions and not specs?
Cancel
We don't have anyone requiring us to create written specifications, thankfully. 

And I just wanted to say that I love documentation like mindmaps and flowcharts. Diagrams really help me to understand designs a great deal better. We've started doing more diagrams using Visio.
Cancel
Abuell

I'm wanting to do an advice-based piece on using mindmaps and flowcharts. Any interest in chatting on the phone about that?

I'm the new SearchSoftwareQuality editor...nice to meet you virtually:).

If you're interested, send me an email and we can take it off the board and schedule a time to talk.
vsilverthorne@techtarget.com
Cancel
Here are some points the author of this article didn't cover: agile teams are reshuffled pretty frequently, how do the past design discussions and decisions get propagated to new team members in an efficient manner? What if one or more of the key design SMEs are unavailable when someone has a question about the design? 
Cancel
Deeper discussions, however deeper they might be, replacing documentation means, making the product depend on the members involved in the discussion.  Once the people are gone, you lost the product entirely!  Further maintenance of it simply turning out to be a nightmare.
By the way, Agile advocates 'minimizing' documentation.  Not replacing it.
Cancel
I think you have to document the discussions to overcome that problem. Even then, you face risks (look at how discussions that start with a user story are often not documented, and the issues that ensue). And that’s one problem with common interpretations of agile methodologies - people don’t factor in the rigor and discipline required of practitioners to document what was decided.
Cancel
This has been an ongoing debate for the past ten plus years, since Agile started making headway into organizations. Agile recommends "just enough documentation", not "no documentation". Somewhere, we decided that conversations were more important than rigid specs. On the surface, I agree, but the danger is those discussions never get captured, or much gets lost in translation. I'd be happy to see a middle ground, or at the very least, as mcorum suggests, make sure those conversations are captured so they can be referenced later. Otherwise, many projects feel little better than "flying blind".
Cancel
"Discussions" are great but it implies that nobody's writing anything down. How do you keep track of what you "discussed" and make sure everyone walks away with the same understanding of what you agreed on?
Cancel
I don't think it is about detailed design specs... I think it has a lot more to do with adequately communicating needs, realizing that the understanding of them may not always be exact.  That's okay if you can learn, change, and adapt over time I think.


Cancel

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

DevOpsAgenda

Close