Ajax Annie made a comment on my last post suggesting that there could be
resistance to agile due to suspected lack of up front design and
documentation.
First I'll give you my honest answer based on past experience - as opposed
to a prescribed agile methodology answer.
You know when you write a functional specification how they are typically
based off a template of some sort with every conceivable project facet known to
man kind? When I have written these in the past - 20% of the document is the
gold and the other 80% feels like pure space filler. Based on template headings
it becomes easy to create an impressively bloated document that doesn't
actually contain a lot of useful information and this annoys me.
You read the average func spec and a lot of it is typically unneeded apart
from the occasional good bit that you don't need to skim over - unfortunately
the other 80% still takes time to write so the good bits can be glossed over
due to time/budget constraints so that the rest of the document can be written.
Why not just really focus on the good bits - the architecture design, how
everything fits together, and make those parts even better and not kid
ourselves that anyone will actually find the rest useful even though it
looks good on paper. It would be great to have the freedom to simply write what
is truly useful without feeling compelled to wrap it with suffocating red tape
and words. They always look so good and acceptable however once done - but once
the project starts I've rarely seen them referred to, apart from screenshots
and expected behaviour on each screen.
Even architecture design (unless it's a high level diagram) I find hardly
any new developer on the project would need to read it - we are coders, the real
and current architecture is documented right there in front of you (and
here is a secret truth - I think that all developers actually subconsciously
assume that documentation will be out of date - so purposely do not look at
it). Scary blow to the head for many PMs I think but I think that's the
reality.
The architecture may also evolve overtime - no design is ever perfect without
the hindsight of what is learnt from actually starting the project.
I think the time would better be spent doing a spike or prototype of what
you are wanting to build - that includes a piece of functionality that requires
the core parts of the architecture to be there. The architecture of what
emerged can then be documented in the planning document (I think at a high
level). You were bound to have found things through that short experience that
you couldn't have predicted on a bit of paper. You could even put this
spike/prototype through some performance tests and deploy it to infrastructure
similar to the target environment to prove that the solution is going to work
before committing to it in a "plan".
As for a complete schema diagram of the entire application before
development begins - yuck. One, I find developers just ignore them anyway and
make up their own tables and columns as needed, very naughty, however a
lot of the time, these end up being just as good or better - because
they are closer to the problem at hand. Why do we need to pre-design this?
Wouldn't it be better to just communicate to the team database schema changes
in daily stand ups so not only one mind is on it, but many?
Isn't it true that there is normally more than one great mind on a project and that if the whole team is involved then there might be a much higher sense of ownership?
Couldn't the same almost be said for the rest of the architecture in general as it materialises?
Is this really uncontrolled? The same people/person that was going to make the initial decision themselves is still there with input and evolved design can be documented after each decision, which at least will be correct, non-outdated - and the best decision that matches the system to date.
Also, no one ever follows the original plan to the dot if there is now a better way apparent (and if they do, there is something seriously wrong). This is because the team can take advantage of truth based on experience so far in the project and ignore silly design simply due to the initial unknown. Then you might think, why waste too much time on this initial design if it is all going to change anyway once the project has some legs behind it.
If that makes PMs nervous - then they probably have a false sense of security about the guidance a detailed up front functional spec provides to a team that normally just prefer to work it out on their own with guidance from a tech lead or peers at the time in a more current world.
I probably went too far the other way - but I wanted to stress the devils advocate to break some typical ways of thinking. An initial sense of direction and plan is definately a good thing.
Here is how I think of agile - I believe the most efficient way of
developing software is a group of friends getting together and just working
stuff out and working together with passion - and that seems to transpire a lot
to how agile methodologies work. There needs to be an interface above this
however to engage with clients so that clients feel comfortable about things, a
lot of the time due to lack of trust.
I think the aim is to make sure this interface however does not impinge too
much on the most efficient way of developing software. I would love to break
the mould and just think without preconceived ideas, what feels right
and natural. Then make accommodations where necessary.