Musings on Tech

From a collection of writings I wrote in 2007 when I first explored this methodology . To sum it up in one short sentence - " Scrum was abandoned ". Many might spin it the way they like, but the hard fact remains. This was really unfortunate given that the process during the initial days were adopted quite enthusiastically by everyone and many really tried to follow it to the best of their abilities. Now at the end of the release (which proved to be one of the more stress full releases), the whole SCRUM methodology - as adopted and followed by us is in shambles. It attracts no credibility among the team and everyone including yours truly is skeptical on the way ahead. At a personal level, I am very disappointed as I believed and continue to believe that Scrum offers significant advantages during the Software Development lifecycle. What attracted me and in which I still see merit are: a) The focus on doing the most important thing (biggest bang for the buck) first

From a collection of writings I wrote in 2007 when I first explored this methodology . We are almost at the middle of our release and have been trying to learn, adapt and incorporate Scrum methodology for about eight weeks now. I think this would be a right time to jot down few points on how we are progressing as I believe that, the initial euphoria/dejection about incorporating a new process has now died down and people have dirtied their hands sufficiently for about four iterations now (we have each iterations spanning 2 weeks). First the Positive impressions about Scrum: Personally I am impressed by the methodology. Forget everything else, by breaking down the deliverables into atomic units, it helps the managers and engineers to monitor the work at on a regular basis (every two weeks) and make appropriate course corrections whenever mandated. This according to me is the biggest bang for the buck. It builds a healthy working relationships between the different stakeholder

From a collection of writings I wrote in 2007 when I first explored this methodology . We are almost two iterations old with this process now and many issues have started surfacing up. Listed below are some of the very common comments I have been hearing over last few weeks. I am planning to collect all the comments (will keep updating this post as I hear new ones) and finally intend to check whether the comments are resulting out of Scrum or will result irrespective of the process. I am frustrated with Scrum. It is not working for me, I am not able to make any progress I am irritated with the number of meetings I am attending. I dont think the meetings are helping my productivity I am forced to sit at a stretch for 3 -4 hours. The discussions during these meetings are more of a dialog. I think we are all wasting time with these meetings. What scrum, we still have the same problems between the Development and QA. Development is not giving us the feature till the las

From a collection of writings I wrote in 2007 when I first explored this methodology . Yesterday one of our Scrum Masters made a comment "What can I do? I have nothing to say. For all practical purpose I am a dummy and it is the team which is responsible". I thought that that was a very stupid comment to make and at the same time was puzzled at that opinion. The textbook definition of a Scrum master is a " person who ensures that the Scrum process is used as intended. The Scrum Master is the enforcer of rules and sprints of practice. The master protects the scrum team from impediments and distractions ". To me this role is quite powerful albeit that unlike a typical project manager, the scrum master does not enjoy the directive controls over the team. But played well, he has lot of leverage to influence the team, lead the team towards right practices and insulate the teams from external distractions. The closest analogy I can think for this role is that of

From a collection of writings I wrote in 2007 when I first explored this methodology . Retrospective is a process where in the team reflects upon the just finished iteration and enumerates what went well, what did not go well, what they should continue to be doing, what they should immediately stop doing, and what new things they should start to improve the process. In my view, in order to do justice to this exercise, the following pre-requisites have to be met: The environment should be created such that, people can open up to air their views The primary focus should be internal (i.e. within the team) with the other stakeholders, being good listeners. They effort should be to understand the views/issues raised and help the team in addressing the issues by providing necessary support and guidance. The scrum master should be an active facilitator who will drive the team towards holistic improvements and ensure that the meeting does not reduce to a forum for finding faults.

From a collection of writings I wrote in 2007 when I first explored this methodology . Yesterday we completed the first iteration and had the scrum review. Given that this was the first iteration, there was sufficient excitement around here about the demos and how we go about it. I am capturing as part of this blog some of my impressions about this ritual of Scrum. Positives: I personally found that Demos were a real good tool for it gave a perspective of what is coming. Since the audience of the demo included people from other teams, it helped them build a more holistic view of the entire development and helped people to spot dependencies. For many of the young developers, the idea of giving a demo to a large audience was a experience and they were very excited about the same. I personally believe that such excitement is of great importance for the team morale. The demos helped in soliciting quick feedback and make the necessary changes before it is too late. Negatives:

From a collection of writings I wrote in 2007 when I first explored this methodology . Last week we had the release planning process for our next release. Given that this is going to be the first release that would be developed in agile, there was lot of expectations on the how to and what to do for release planning. The general idea was to get everyone who would be the primary stake holders for the release (which ironically ends up being senior leads, managers and architects, and product managers) in a single room and trash out the skeleton for the next release. So we had people flown in from US for a week, to be with us in a room to trash out the release contents. Listed below are my observations from the release planning experience. The Process - Get the backlog out - It should list a set of items which is desirable for the release and the priority of the same - Have some offline discussions and research to determine what is involved for each of the item - Give a approxim

From a collection of writings I wrote in 2007 when I first explored this methodology . Do Managers have a role in the Scrum Process? This was the question that was raised when we were discussing the Scrum Process yesterday. When this question was asked, I had no concrete answers. So today spent some time checking out the web for clues to answer the same. This link (attributed to Jeff)  addresses this question. Reading through that, it appears that in the Scrum world, the role of a “First line Manager” is morphed to that of a mentor and coach, with primary responsibilities like Provides organizational vision Removes impediments ( a role shared with the Scrum Master) Assists with individual development Challenges team beyond mediocrity while respecting team boundaries Helps individuals without sucking the responsibility out of the team Provides the right environment Gives individuals tools to be a great team member Coaches teams through conflict resolution Advocate

From a collection of writings I wrote when I first got exposed to this methodology around 2007 . At the workplace, there has been a sudden impetus to adopt this methodology. Whether we like it or not, we would eventually have to adopt this as there is a tremendous push from the top. Hence have been reading up some stuff and trying to relate it to apply it to my daily professional way of work. From what I have observed, I believe the methodology is promising. It would invariably help in the kind of work we do. Some of the inherent positives I see include: The focus on the working software over extensive documentation  - Most of the time documentation is out of sync with the software and is created more as a ritual than as a knowledge base. The incremental Development approach  - Will provide better control and tracking of the projects. The collective responsibility on the team  - I expect the peer pressures to build accountability to the members of the team and would hopeful