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

  " continuous integration  ( CI ) implements  continuous  processes of applying  quality control  — small pieces of effort, applied frequently".   - Wikipedia Is continuous integration  another one of the buzzwords that goes round in the Software industry or does it merit serious consideration.  This post is my attempt to answer the question based on my experiences. Short Answer -  It is not a fad. If implemented with the right focus and intent, Continuous Integration can help organizations realize immense value in terms of time required to release software and the quality with which the software is released . Reality Check:   Have seen numerous instances where Continuous integration becomes an exercise in itself. The discussion on the process and how to implement the same extends for months if not years, and still folks struggle to realize any value out of it.   Every system or a process tries to address a core problem area.   In my view the core proble

Yesterday, one of my friends asked me a very interesting question.  He asked me "How would you define a good Engineering Organization"?.   Both of have spent long years as part of various Software Engineering organizations and hence was very surprised that this question was brought up. We ended up discussing various aspects of a good Engineering Organization for quite some time. So the idea behind this post to provide my take on  a "Good Engineering Organization" and also to consolidate some aspects that makes a particular organization great.   caveat : The post is based on my experiences in Software industry, where these kind of Organizations are referred to  by names like "Software Development Organization",  "Product Development Organization",  "Software Engineering Organization", etc. In my view, the core charter for an Engineering Organization is  " to ship (or deploy) good quality, usable software  in the fastest

" Keep things simple stupid.. ." The best way to answer this question would be to ask whether the Quality with which the product is being shipped is sufficient for the Customer. It goes back to our old theme - "Customer interest is paramount". Having said this, making a decision of whether the quality is sufficient from the customer perspective is a tricky one. Many issues gets raised on what is sufficient for the cusatomer and let us face it is a difficult call to make given the pressures on time to deliver and impact/side effects due to a fix. Personally, I use the process listed below to evaluate the product quality. Base Rules - QA should have the same time (if not more) as the development to test the product. Most of the time QA lags the development and hence there is a learning curve for the QA. They need to know the features first, before they can start trying to break the features. - QA should have exercised all the features of the release in an in

I am sure that anyone who has gone through a complete software life cycle will understand what I am talking about. As the release date starts nearing, discussions starts on the number of defects that are still open and how we plan to address the same. This debates proceeds almost till the date of the release and many a times as the software is released, a plan for the "Service pack" that will address critical issues that have seeped through the product is put in place. Many of these discussions are painful and one of the primary reasons for the pain is due to the different perceptions on "Quality" of the software and whether one can say with a "clear conscience" that the product is ready to ship even though he knows that there are defects in the software. Obviously a good software practioner will not want to cause undue to pain to the end user of the software. If one scans through the litrature on Software quality, we will find two broad views. One v

Whenever the subject of Software quality is broached, immediately the arguments pertaining to the various constraints that binds the quality of software gets raised. So what are these constraints and how deeply they affect Quality. Before we take this discussion further, we need to root our discussions on one golden rule - "Customer/User is the King" and in case of any trade-off, the trade-off will be made in the best interest of the Customer/User. The second aspect we need to be clear on is, whether quality is an independent or dependent variable. I posit that, quality is a dependent variable and is always subject to constraints placed by other factors that the stakeholders of the software can control. Extending this argument further, let us look at what are the factors that control quality. By doing so we also get back to the idea behind the post i.e. the constraints on quality (more in context of software engineering). As I see it, the primary constraints that affect so

Over last few months, I have been privy to lot of talks on Software quality and how we need processes and tools in place to improve software quality. This discussion brings up an very interesting question. What is Software Quality? Basics first. Let us start with the definition of Quality: IEEE 610.12-1990) Standard Glossary of Software Engineering Terminology defines quality as: the degree to which a system. component, or process meets (1) specified requirements, and (2) customer or user needs or expectations (ISO 9003-3-1991) Guidelines for the application of ISO 9001 to the Development, Supply and Maintenance of Software defines quality as: the totality of features and characteristics of a product or service that bear on its ability to satisfy specified or implied needs . If we are to go by these definition, one thing becomes very clear. Quality is a function of user needs. As long as a product meets the specific requirements or needs of the customer/user, then it is con