Crude Java and Agile thoughts
Category Archives: Scrum
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
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
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
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.
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.