Being agile… Part I


The noise level about agile software development is deafeningly high these days. May be it has already peaked, which is probably a good thing.

My real encounter with agile development in a production environment happened in 2003, when the company I am working for decided to adopt agile practices. We were playing with Fish philosophy before that. That was quite amusing and often gave me of an Office Space feel. It was like someone was trying to pour happiness down my throat.

When I was sitting in the early presentations and crash courses on agile, I was quite skeptical in its adoptability for our code base. Our experience of the first three years of agile was presented in the 2005 agile conference (Teaching a Goliath to Fly). 5 years after that paper, we are still agile, more so.

So, among all the other noise, I will add mine as well.

I am planning to write a series of posts about the interesting facts, realizations and revelations during this time, my reflection on the larger state of affairs etc.

First of all, I believe the spirit of agile development is its lack of rigidity. Unlike the earlier, well defined software development life cycles, which specified (sometimes including visual/text format) of artifacts that are to be used in each stage of the development, agile presents some basic principles. There, of course, are attempts by many to present such over specified artifacts in agile as well, but, it is an exception, not the rule.

It all comes down to the realization that software development process is quite messy. But any complex human endeavor is messy, especially ones that involve a lot of abstractions. In many engineering practices, we have managed to come up with systems and practices that controls this messiness to a very large extend. However, if you have ever associated with a construction project, it is easy to realize that with all the plans and architectural drawings and RFPs etc., the final product turns out to be quite different from our original conception about time, resources and form. But, since we know the costs involved in making a change, we just try to live with it.

In case of software, there is a common assumption that it can be altered quite easily – that it is soft, and malleable. It is also quite abstract even in its final form. It is a model of the real world, a simulation of a series of behavior patterns of the store front clerk, physical movement of a bunch of trucks. They communicate tersely with the user, mostly in verbal, or in highly iconized visuals. We create this model through a series of layered abstractions from real world observations, verbal descriptions, mathematical equations and finally the implementation tools (programming language, testing tools, modeling tools etc.)

Many early attempts at controlling the messiness of software development did so by controlling change. Mimicking other engineering disciplines, we tried to create detailed design artifacts, elaborate triaging procedures for change control and sometimes downright scare tactics! Every stage of the development created these huge walls of artifacts between its predecessor and successor. And as with any wall, it seeded animosity. I remember, in my previous job, I met an actual tester only after several months. But, even before meeting one in flesh, I was quite happy to trash them and developed quite a distaste in their ways. We did the same to the “architecture team” whom I never met in my two years there.

A significant symbolic gesture we did, prompted by Ken Schwaber was to demolish the walls of our cubes. Our cubes had 5ft high walls and you could only see the person sitting right across you. The window cubicles were a status symbol. It also separated the programmers from the testers and from the BAs quite effectively by placing them in different areas of the floor. It was a shock to a lot of people to lose the privacy of their cubes. Many complained the new “team rooms” are too noisy, Ken complained that we are too quiet. (The team I am in now has the honor of being the noisiest!)

We were officially following SCRUM and agile. But, the nature of our products made this adoption quite challenging. Since we are developing packaged software, there is not a lot of direct and immediate interaction with the end users, and the release cycle is typically span an year or more. The adoption of new versions by customers is even slower. There were serious doubts about the predictability of iterative process. We were changing things so very often. Trying new ways of planning, inventing complex sticky notes schemes, pairing and not pairing, fighting over differences between unit testing and acceptance testing.

One thing we did not do was adhere to a single set practices.

Advertisements
Tagged ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: