What is Agile Methodology?

Okay, there are several sites, several resources that can give you definitions and ideas about what is Agile and how different is it from any other form of software development. I once explained it to a group of friends and I felt, I was able to capture the essence in a simple example. Here it is, for some more of my friends out there who want to know what is 'Agile' in simple english.

Normally, the software development life cycle (SDLC) has certain stages, just like a document development life cycle (DDLC) - Planning, Analyzing, Designing, Developing, Testing, Documenting and Packaging in more or less the same order. What we were doing before 'Agile' came in - the entire development team (and before them their managers) would plan, analyze and design the software solution. For example, if a company wanted to make a water bottle, they would plan how best to make it (with minimum resources, minimum effort and using a fool-proof design).  After they come up with a way to go about making it, there would be discussions over the best method and then implementation would start off.

Now, the developers would go on coding, piece after piece and the testing/documenting/stake holders would have no say, no idea about what was being developed. After a long time, when the development would be almost 70% done, and developer self-tested his effort/output, testing team would come in. Not only this, the entire bottle would be 'developed' as 'planned' two years ago - meanwhile - the stake holders ran the risk of the 'bottle' being 'outdated' by the time it hit the market!

Phhissshhhhh....here comes Agile.

Now, using Agile methodology, what happens is - everyone is involved in everything. Plus, there is no 'long wait' and 'isolation in tasks' while working on the same product.

Precisely, what happens is - the entire bottle is not planned for. It might be a 'top-level target' but what is considered as a goal is - say, 'the bottom of the bottle' or 'the cap of the bottle' at different stages. This way, small pieces of the big product are created in smaller time lines  and not just the testing or documentation team comes in early onto the platform; they even start delivering very early. For every piece of code (functionality or feature) that is developed, testing happens, UAT happens and documentation also happens almost simultaneously. Plus, the best benefit is that there is a very little time spent on bringing the pieces together while packaging. 

The effect is - we start with the base of the bottle and run it through all stages before declaring it ready for delivery. Similarly, every new piece that is built upon can be run through with the stake holders much before the entire bottle is ready to be shipped. Obviously, it makes lot of sense to get the 'base of the bottle' approved and look for ways to enhance it - before putting the lid on the product.

Your comments are welcome. :)

Writer's Block

I know, I know, as an experienced writer I am not expected to start my knowledge sharing sessions with such a title. I have been wanting to write about what I have learnt over the years about 'Writing' and frankly, never made time for.

I am just writing this post, hoping this would inspire me to write some more of the useful stuff. While thinking of where to start, I am feeling lost.

Let me just create this post to write down all the topics that I can reasonably explain:

1. DITA and Topic-based writing
   
2. Writing using XML
3. Instructional Designing and Technical Writing
4. E-learning
5. The changing role of a Technical Writer
6. Mentoring Technical Writers
7. Adopting the right attitude while writing
8. The need for audience analysis
9. Besides being a writer with an organization
10. Managing the Manager

I don't plan to make Help tutorials exploring Word/Excel or any other tools. I believe the knowledge of tools (basic and advanced-level usage) can be easily picked up if you have the willingness to learn. Besides the willingness, one needs a chance to explore the tools and the best tests come when you learn while on the job. What one 'need to get it done - how?' trying time - can teach you, is going to remain with you much longer than reading three or four books.

I help create books and I enjoy reading, and I don't deny there's wealth in books. What I am saying is, from my experience, what I have had to struggle to do, has remained a bitter-better lesson when compared to just a 'do-it-like-this' session.

Maybe, this is the primary reason, if I am working on an e-learning tutorial, I would prefer to make the user 'do' what is 'taught', rather than just quiz him on theory. Ah! does saying so mean I am supposed to add a 'do it yourself' section at the end of each post in this blog? I might, if it makes sense. I leave it to the readers to judge for themselves whether they need to work on that section. :)

My First Tech Writing Related Post

Being a Tech Writer with reasonable experience, I have been feeling compelled to be of use to the Tech Writing Community (read Peers!). Let's see what all I can recount (showcase) here for collective benefit.

Tasks are small,
Ways many;
Doing it well,
Wish of any!?!