Random Colors

Crude Java and Agile thoughts

Tag Archives: Agile

Distributed Scrum Practitioners

Nowadays Agile is almost on its peak of popularity, and Scrum is on everybody’s tongue. I see Scrum being followed almost everywhere. I even came through videos where kids were using Scrum to manage their tasks. I see small/big projects using Scrum to deliver quick and superior products. I see questions and curiosity about Scrum. There are groups where people discuss, share their Scrum pain points and other areas of improvement.

However, Distributed Scrum definitely not as easy as plain Scrum is. It involves geographical, cultural and chronological issues. It has its own set of rules. To have a successful distributed Scrum team is not at all a piece of cake. Read more of this post


Extreme Programming : Designing Using CRC Cards

I recently did an experiment by designing using CRC cards. I did with my team and found it quiet useful and comfortable. The design outcome of this process was also the team’s design rather than one person’s design. Also, as everyone participated in the designing the design was better than a single person’s design. Please read the complete blog on my official blog site and share your thoughts.

Scrum – Too Many Meetings

You will often find people in Agile teams cribbing about the overload of meetings. Initially I also cribbed. Then, with time I became more “Agile” and then thought “communication is a key feature” of Agile. I tried to attend meetings with interest. However, I always tend to return towards cribbing about “Overload of meetings”.

So, I thought that there must be something wrong in my interest towards meetings.

The irony was, I always attended other non project meetings with great enthusiasm and participation. So, I tried to capture the impulsive moments of boredom in meetings when I my interest drifts away from the subject.

One of the major points was beginning of discussion on topics which were not planned for the meeting. So, in this scenario, you expect one thing and the result is something else. So, if you are not prepared for what is being discussed, you will feel isolated and get into your own world. Read more of this post

Why Agile Does Not Work

Have you ever been part of/witnessed a team trying desperately to adopt Agile, and the more they tried to adapt it, more hellish their life became ?

I have seen agile adoption failures. And what I have learned from that experience is, that the problem was not Agile. The problem was the way, the processes through which they were adapting it.

The idea of writing this blog originated when I attended the Certified Scrum Master Training few days back. Apart from my colleagues, who are Agile specialists, and really young for this course, I didn’t find any veterans at all. Other than that, most of the people were quiet experienced PMP certified core project managers. These experienced people, who have been working in a completely different environment, following a king-slave sort of process with engineers had become too rigid with time to be mould in Agile. Read more of this post

Scrum Team Size Dictates Productivity

I have been working in Agile Scrum teams all my career. I have worked in scrum teams sizes of two, three, four, eight, twelve and twenty. I have even worked in geographically distributed teams. It has been quiet an experience to work in teams of these flavor.

The team dynamics basically decided the team’s productivity. Here we measure productivity by the number of user stories burnt, the health of the code, the distribution of business/technical knowledge among the team members, the ease with which the team works with each other and the inverse of amount of discussion that happens before implementing things.

Larger Team Size

While working with teams of sizes greater than four-five, I found out that it was quiet difficult for every developer in the team to know about all the code written. This is a great drawback in Agile teams. Generally there is no or very little documentation about the architecture/design of the code.

Read more of this post

Agile sprint backlog change in middle of the sprint

Well, agile strictly says no to changing sprint backlog in middle of the sprint. However, I have faced and seen situations where changing sprint backlog looked really logical to me.

The customer builds the product for selling. It’s not showcase of a perfectly modularized, architect-ed, unit tested and agile followed product. Its build for creating money, apart from other reasons like showing the creativity of the thoughts of the product owner.

Read more of this post

Pair Programming Issues

Unlike most of the people writing on Agile, I have only two and a half years of experience in software development. But that’s not the only unlikeness, unlike most of them, who were born in “The waterfall era”, when I was born in software industry, Agile was already quiet famous, and that’s the only software development process that I have worked upon. So, I am completely unbiased towards waterfall, I have just read and heard (from senior colleagues , both praises and slangs :))  about it .

I have seen people migrating from different development models in Agile. I have also seen few freshers (like me) being born in Agile era directly. And after a very short interval , almost all of them feel it’s a very comfortable and efficient way of software development. I agree too.

However, when you will read about Agile, re factor and rewrite will accompany it everywhere. Why So?

We all know that change is unavoidable and we must adapt ( so must re factor). But the amount of re factoring done in agile is awful. There has to be some reason behind that and I think its pair programming.

Lets see why I blame the pair programming:

  • Generally people don’t think a lot while pair programming as the person who wants to think about the pros and cons will be considered inefficient (as he will slow down the coding speed). So, generally people show fake confidence on the effectiveness of the proposed solution. Some common comments will be (“We will change the code if problem occurs”). The re-factoring tasks generated due to this type of attitude is the outcome of pair programming only as no single person can be held responsible for the mess created.
  • One of them suggests solutions very fast, which are always crap, and will always need a reimplementation . His pair has to find the loopholes in the proposed solution in almost no time. If not, he has to go with the proposed solution. (And it’s not necessary that the fastest solution will be the best one).
  • Persons having aggressive and inhuman behavior will make their decisions accepted (even if his pair is having a better solution).
    When two persons pair, the entire code flow is neither of them, as two persons can not think exactly same things at same time. So, the outcome is a spaghetti of their thoughts which will need re factoring for sure.

Read more of this post

%d bloggers like this: