Depends on the project, if you are working alone on a small project, it might make perfect sense to perform your tech research and investigation as part of the development. And although not a part of Agile, of course an Agile methodology could be used to add some control to this. However this makes the process very hard to predict /or time box. Might be fine, even faster, if working alone on a small project that is wholly yours, let your requirements unfold as you learn them. Use good principles along the way, and be consistent and you shouldn't need to re-factor so much.
At work we use Kanban, Scrum, and more traditional waterfall approaches. Depends on the project, I find that complex developments with well defined up front requirements are not best suited to agile, many will disagree though.
Before we start work even on an agile project (all but the most simple that is), we create some documentation. We have a mock up (if ui focused), a set of requirements, and a functional spec.
Development will be asked to create the technical spec from the functional spec, and during this process we will specify technology and perform any up-front research that we need to. This process seems so important to me, as it gives the opportunity to see gaps in the requirements / functional specs - and gives the big technology decisions up front to the people with the experience and system knowledge to make such decisions.
The significant thing though, is that the functional spec could be a list of bullet points, and the tech spec will usually be a model, with some bullet points and technology steers, maybe just 3 or 4 pages in some cases.
Even when running an agile project we create documentation:
- All documentation has a cost.
- Developing against moving and ill-define high level requirements has a cost.
- The correct balance to the above depends on your project, the culture, and the people.
- We document Just in time, documents come out of date.
- We document barely enough / just enough.
- We do not maintain or update these documents, we don't put much effort into them. They are small. We expect to throw them away.
- We iron out the big unknowns such as technology decisions, hazy requirements, and architecture up front.
- We know what we are developing before we start.
- We trust the developers to make informed decisions around the documentation and discuss any issues.
- We value communication over documentation, as such we expect all involved to communicate often.
- We document systems (overview) after development, not during, not before.
You see there is a small waterfall in our agile process.
If you work alone, create an upfront model (diagram!) and play with and choose the tech, and then when you have this concept of the high-level requirements, run ahead and develop in an agile iterative way, but consider good principles and consistency as you go and you will need to re-factor less, more re-factor as you go.
But in general, if there is a real cost involved (not a hobby) know what your are developing before you write code, but don't waste too much time writing documentation that will become redundant fast as you will change your mind, and should change your mind during development as you become better informed. And your project could change course hugely, but start from a good, well defined foundation.
