Console.Read(); // “Start reading damn it!”

I was never a good reader, never liked reading really. Guess that’s why I never got good at it. I tried really, I made several attempts on starting to read a few classics by Charles Dickens that I got given at college prize giving when I was leaving school back in 2001.

Thanks to Tim the other day, for what he said over yum-cha that inspired me; “If you want to be good at what you are doing, you’ll have to read.”

Agile development, Extreme Programming, SCRUM etc have been buzzing around the community for a while now, and I’ve decided to take a dive into it and see for myself. So here I am, picked up “Agile Principles, Patterns, and Practices in C#” by Martin C.Robert, Martin Micah and started reading it.

So, I’ll kick off a series on Agile Development as I progress through the book. I’ll blog about concepts/code examples from the book that I think are interesting / eye-opening, doubts that I have over what I read etc.

Here is something I read and reflects on me and work fairly well, unfortunately. Here I shamelessly quote from the book, it’s something I call;

Process Paradox

“Many of us have lived through the nightmare of a project with no practices to guide it. The lack of effective practices leads to unpredictability, repeated error, and wasted effort. Customers are disappointed by slipping schedules, growing budgets, and poor quality. Developers are disheartened by working ever-longer hours to produce ever-poorer software.”

“Once we have experienced such a fiasco, we become afraid of repeating the experience. Our fears motivate us to create a process that constrains our activities and demands certain outputs and artifacts. We draw these constraints and outputs from past experience, choosing things that appeared to work well in previous projects. Our hope is that they will work again and take away our fears.”

“But projects are not so simple that a few constraints and artifacts can reliably prevent error. As errors continue to be made, we diagnose those errors and put in place even more constraints and artifacts in order to prevent those errors in the future. After many projects, we may find ourselves overloaded with a huge, cumbersome process that greatly impedes our ability to get projects done.”

 “A big, cumbersome process can create the very problems that it is designed to prevent. It can slow the team to the extent that schedules slip and budgets bloat. It can reduce the responsiveness of the team to the point of always creating the wrong product. Unfortunately, this leads many teams to believe that they don’t have enough process. So in a kind of runaway process inflation, they make their process ever larger.”

I’m not sure how many folks out there have worked / are working in a situation like described above, I’ve certainly experienced the first part this account. Unaccountable number of delayed dealines, countless number of working-till-next-morning-days, very unsatisfied customers/managers. Most importantly, loss of team morale, developers no longer have faith in the products they are building or simply don’t care…

So, what is the “silver bullet” to this process paradox problem (if you believe this problem does exist), agile development? I certainly hope to find out from this book as I progress through it. Watch this space… 😀


Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: