A big part of being agile is doing ‘Just Enough’

Just Enough Requirements: The idea is not to get down to the finest details up front, capture just enough information which will enable team to estimate the development time for the requirement (in a form of user story) with a window to have a discussion with customer at a later time for the needed functionality. By going lazy with the requirement gathering, we are sure what is being developed is really what the customer want. Guy Beaver supports this in his article on The Challenge of Enterprise Requirements Management

The suggested solution is to replace early detailed specification with solution road maps that can be detailed by collaborative teams at just the right time. Agile methods provide the structure and mechanics to allow business vision to lead product development with cross-functional teams that unfold detailed requirements when needed

Just Enough Documentation: Agile does not mean no documentation, it means effective and just enough documentation written when required for a targeted audience which can be kept upto date. There is already a discussion on InfoQ on this. Do Agile Methods Require Documentation?. Kevin Aguanno in his book Managing Agile projects talks about agile documentation

The easy answer is that agile documents, like agile models, just need to be barely good enough.

Matt Simons agrees

There are two keys to successful documentation on agile projects. The first is finding the point of “just enough” documentation. This is difficult to determine and will vary by project

Just Enough Tooling: Chris Woodill has written a lot about the techniques and benefits about having just enough bare minimum tools for requirements gathering. here.

One of the tenents of agile development is just enough documentation. I would recommend adding another suggestion: just enough tooling.

Just Enough Design: Never do Big design up front as it is going to be a waste, but still most of the project do need some basic architecture and design. But how much, may be just enough to get started with the implementation and get the team going. The design most of the times evolves over a period of time anyway so no use doing something big upfront. We should design for what we know now rather then assuming and designing for later. Here is an interesting piece on how much design is enough

So does this mean that we shouldn’t do any design when working in an agile environment? Of course not. It just means that we can design for what we know about today, and stay disciplined enough to go back and modify the design if we learn something new tomorrow. So we want to just design the feature we’re working on today, keeping the big picture of the system in mind. At any time the system design should reflect what the system actually does, not what it might need to do someday

Just enough Code: This is the basic idea on which TDD is based, first we need to write just enough code to fail a test and then just enough code to pass it, no more no less. Implement just enough functionality for today and not for tomorrow as most of the the time you ain’t gonna need it.