Prasanna's Diary

I happen to remember my brother and his comment as I write this. This was when he had just finished his doctoral thesis, he said "When I finished my bachelor degree, I thought I pretty much have a good grasp on computer engineering having spent 4 years in it, when I finished my masters I realized that I may not know all of computer engineering but definitely compilers, but now that I have done Doctoral work, I realize that I know nothing in Computer science!". He has been one of the best persons I have seen who can provide a simplistic yet strong conceptual view of anything that is cryptic. The key point is as you move up the knowledge maturity, the softer tendencies and philosophies of being human takes over than the actual knowledge itself. If you take Software Engineering process, I see a similar view on maturity and see Agile taking that paramount step in the progression of Software Engineering Process. Software being a Knowledge based workshop, people come before process...

The question I keep pondering, "when do you use agile?". "can you use agile for Fixed price projects?" is another question that is being discussed frequently and recently in Agile Alliance. Well, read on my thoughts ... You should use agile when you cannot define requirements to the last line, when you are not clear exactly what you want and these wants potentially change depending on what you see. It is ironical that more often than not, this is the case. Hence you should use Agile more often than not. When the requirements are in various levels of grey, agile works very well - like a dream. The key there is that details are expected to come later but commitments are expected without the details. If you try to get the details in such a case, you are force fitting a wrong peg. It is in such situations, teams should accept the shades of grey and work towards achieving business results. Will they end up achieving exactly what they want - yes. The reason is simple - no...

There are some good discussions going on in Agile Alliance . One discussion that caught my attention was around "Will we break scrum by allowing changes coming in between iterations?". Clearly by first principles the answer is YES. But that should not stop there. Why would one ask for change within an iteration when the iterations themselves are short? The design of agile is not to get into such a need. But life is hard, the unknowns are much more and hence there may be reasons when product owner may want a change coming in and can potential convince the teams to take it. In such a case, it is absolutely acceptable for the teams to take it up, rather than being rigid on this criteria. However, these changes will be taken with some compromises on the committed scope for the iteration. The main point to take home is that agile runs on the Agile Manifesto and not a process definition. The agile practices are frameworks that SHOULD be tailored depending on team dynamics, streng...

While agile promotes self-organized teams, more teaming, team goals rather than individual goals, I was wondering what happens to performance reviews in an agile organization? Should you look at promoting team work by appraising their performance by teams OR use individual performance appraisals to run the age-old performance management methods? If teams need to be promoted, can we then use models such that teams themselves appraise to avoid the management coming in their way to prove what one acheived and what one did not achieve? These are intersting quetions to ask, I am still looking at strategies that can really be easy to implement, comprehend and finally that which is tamper free for teams to hold their heart and say I deserve what I am getting. Basic foundation to make this work seem obvious: a. Clear communication of the goals: All the teams and infact the entire organization should be clear of what is the final goal to acheieve. This will help the teams to understand how they...

I was having a chat with Kabir in my team on the train, and he brought up the concept of "waiting room" that is used in the agile world to park a user story that is not yet "defined" to an extent that it can be taken up for development. The user story may be needing a spike to evaluate feasibility or not defined enough to roll it into an iteration. The concept in itself is a great one, but when I was linking this back to the Agile train, it dawned on me that User Stories can infact be compared to a Passenger and the more the passengers, the more the scope that gets delivered. Bingo! When you extend this, you will also realize the need to have stations go through the steps of Initial, Defined, Planned, Completed and Accepted. The faster you get a passenger to Accpeted, the better your 'velocity' will be. A person outside the train can actually see the train delivering goods and its ability to to reach destination within the specified timeline. The dashboard w...

I saw a ClintEastwood movie named "Invictus" last week, and could not resist but write this one. It may be because I am seeing everything with Agile lens but this gives us a wonderful view on the Leadership skills and fore thought that Mandela had. The focus on breaking the chinesewalls that get formed by the blessed and the not so blessed is very important in any team work. The movie depicts this very well and provides a very clean view on the importance of leadership to help implement the same. "springboks" making it to the finals and finally winning the match and more than that winning the heart of 40 million South Africans is inspiring for a person embarking on this journey. While integrating the two begins as an impossible and formiable task, the movie unwinds an approach of supporting the cause of one team while focussing on the larger goal is a very nice illustration of the problem and a possible solution. Agile is about team work and cultural change to break...

Another one that stems from the Agile delivery is something that I have closely seen, an undivided Hindu family, essentially a large family which grows as people in the family expand by marrying or having children but live in the same house. Let me explain what happens in a large undivided family, the home they live-in will be a traditionally owned large house having the ability to expand to support additions. Any new additions are only a matter of extension of a room rather than buying a new one. The roles people play within a family are very well organized and in fact self organized. There is no clear roles and responsibility but everyone put their hands together to get the job done. In fact, sometimes skills are cross learnt to support lean times. But the beauty is that they all savour dinner or lunch or breakfast with complete enjoyment. These are the short term milestones that brings back the entire family together to talk about long term and short term impediments to resolve. The...

The software industry in India has really taken a toll on the IT employees. There have been plenty who are talking about exhaustion , retirement and moving out of the industry after 15+ years of hard experience. These are some of the stalwarts, greats who have done well for the IT service industry. The key reason has been that they have put in long midnight hours to bring a new project, work on bring the the projects into control and just executing this cycle with different pace, complexity and size but the cycle has been the same. When you take a step back at these instances, it is very evident that the industry will very soon take the exhaustion path unless we device a mechanism to bring in the joy of the IT journey at everything we do in IT. I have found less and less people who enjoy what they do, and always have a reason why they do not like what they do. The key is 'What is the joy factor of the Indian IT industry?'. Improving this is hard both individually and collectiv...

Back into the Blogging mood after long years! The reason is simple, I did not have much to share than the mundane stuff that kept on running for the last few years. I am back because I am now beginning to implement agile development process for a large team and am discovering wonderful stuff as and when I plough through the details of the agile delivery model. There are a lot of anologies that comes to my mind and I will keep writing these as a beginner trying to unravel a new world. First is an anology that I draw to a moving train. In agile you make timeline constant but scope the welcome variable (which is exactly the opposite in Waterfall), this means how often you deliver to the outside world is constant, but what you deliver is what you play with. A moving traing has stations and their locations constant (where/when) and how many people you move across is a variable. When you start with this basic analogy, there are a lot of things you can draw and ensure various roles are unders...