Today is Tuesday, 7th August 2018

Archive for the ‘Scrum’ Category

The Myths and Realities of Agile Development

Agile development is undisciplinedAgile methods have clear rules to be followed
Agile development is unplannedPlanning takes place iteratively
Agile development is unpredictableHistorical data is rapidly assimilated to reduce uncertainty
Agile development does not scaleLarge-scale projects are being delivered right now
Agile development is just a fadMost individual practices of Agile have a long history of success

Agile, Scrum, XP …. I’m All In!

In the past couple of months, I’ve developed an interest in the Agile software development process. The funny thing is that I’ve worked on “Agile” projects in the past, however we only used bits and pieces of Agile. In fact, we only picked the areas of Agile that we liked such as unit testing, frequent releases and continuous integration. The areas that we didn’t like were daily scrums and pair programming. I would say it was more of our corporate culture on why didn’t adopt daily scrums and pair programming. At the time, we felt daily scrums were a waste of time (why not just send an email w/ status updates). Also, the pair programming intruded on our personal space and private time for listening to music on our ipods. I know, very silly in hindsight but I’m sure you understand where I’m coming from.

And if that wasn’t enough, the developers on my team started conjuring up conspiracy theories about Agile development. In the hallways we would grumble that “code sprints are a euphenism for mini death march”. We thought the daily scrums was a diversionary tactic to micromanage the developers.  Oh boy, as adults we do not like change….

Lately, I’m starting to come around. After doing a good deal of reading on Agile, I finally understand the benefits of daily scrums and pair programming. I wasn’t aware that the scrum meetings where time-boxed to 15 minutes. I can do that on a daily basis 🙂 Also, the pair programming can work out fine if we have a well-defined task. For a given task, we can set up a pair programming session for 2-3 hours. That is doable and we’ll probably be more productive than one developer in an 8 hour day. Previously, I dreaded pair programming because I thought I would have to code for 8 hours a day with another developer sitting on my shoulder. But, 2-3 hours per day is okay.

Anyways, I’m Johnny-Come-Lately to the Agile party. But now I’m all in! Here’s a list of books that I just purchased. My plan is to get through them in the next month.  Wait, should I define that as a “sprint” ??? 🙂