Archive for the ‘Agile Methodology’ Category

What is common between Agile Methodology and the Three Monkey story? Its simplicity!

February 5, 2010

It has been some time since I have blogged about any topics associated with Agile Methodology. Quite honestly – over the last 1-2 years, I had started observing that a set of simple and beautiful guiding principles were getting over-stretched and over-strained and over-complicated by few individuals/groups/companies possibly to out-do the others or simply to rake in some money. IMHO, much to the detriment of Agile – a simple concept was getting converted into a complicated science. This is when I started switching myself off. Well, until this week…

This week I refused to attend an organization mandate to undergo training in Agile. For me, the word ‘training’ threw me off. What was there in Agile that required training and could not be learnt by simply reading? It is one thing that one does not know what Agile is (so one just has to read about it), but the premise that one needs to undergo training in it somehow creates an impression that we are dealing with something complex. Quite honestly it is not and the complexity in it is a man-made thing.  Let me explain why I felt that by giving a slightly non-related but similar example.

Almost all of you must have seen the three wise monkey picture – popularly also known as Mahatma Gandhi’s Three Monkeys (see picture below). These three monkeys represented the proverbial principle – “see no evil, hear no evil, and speak no evil”.

Three Monkey Methodology

Three Monkey Methodology - Is it complex to understand?

For the sake of this blog post let me call these principles as  “Three Monkey Methodology“. What I like about this methodology is that it clearly describes the three maxims (i.e. see no evil, hear no evil, and speak no evil) in a simple and crisp way such that it is self-explanatory to almost except possibly five (or less) years old. The additional thing which I like about this representation is that they have not tried to explain it in any more details and have left it to the understanding of the individuals as to how they would like to interpret it based on their surroundings and experiences.

Now imagine if this Methodology evolved today. I have strong feeling that in today’s world driven by hype and monetization  (analogous to what is happening to Agile Methodology) – we might have seen the following –

  • Paper or Book Titles – “Three Monkey Methodology for Product Management”; “Applying Three Monkey Methodology to Configuration Management Practices”; “Learn Three Monkey Methodology in 3 days”; “Three Monkey Methodology for Dummies”, etc.
  • Training Courses – “Three Monkey Methodology for CEOs”; “Power your Engineering Team with Three Monkey Methodology”; etc.
  • Certifications – “Certified Three Monkey Methodology Developer”; “Three Monkey Methodology – Level II Certified”; etc.
  • Marketing Messages – “We provide engineering services using Three Monkey Methodology”; “Best Three Monkey Methodology Expertise Shop in Town”; “We follow Three Monkey Methodology in all our Departments”; etc.

Once the activities or messaging such as above begins to happen, our simple Three Monkey Methodology suddenly now starts to appear or feel complex. However, hopefully you will agree with me now that this complexity is now a man-made thing and not inherent in the methodologies principles. This is exactly the same way I feel with this whole Agile thing.

Similar to Three Monkey Methodology – IMO Agile Methodology also has four maxims (check out the Agile Manifesto) written in simple yet crisp manner and left to the interpretation of the Software Practitioners for its implementation as they see fit. The hope there was that anyone who had experienced Software Development even in a slightest manner would be able to understand where these four guidelines were coming from. There-in lied the beauty and power of these four principles. Simple yet powerful enough to be individually interpreted and applied to real-word circumstantial scenarios!

In my opinion, the challenge started when few started taking the ownership of interpreting Agile and forcing that interpretation on others. This is where the essence of Agile was lost because it opened the doors for over-complications, mis-interpretations, un-required group’isms, consultants, trainers, etc. while closing the door for plain vanilla common sense. Agile was meant to be simple and it needs to remain simple. As simple as the Three Monkey Methodology!

Look forward to your thoughts and comments!

[Update|Feb. 17, 2010: Looks like there are others too who are thinking that this whole Agile and its associated certification/training beginning to sound like more of a marketing gimmick. Read the article (along with the discussions at the bottom) titled “Is Scrum Certification Having Another Makeover?” published at InfoQ.]

Honey, I destroyed my product by adding too many features!

November 30, 2008

The temptation associated with squeezing in as many features before it gets into the user’s hands is typically very overwhelming for any product entrepreneur. This is especially true when a new product is being launched in the market for the very first time. A typical assumption behind this is that the probability of users accepting the product is directly proportional to the number of the features which the users find in it. The notion that the products just have one chance to get to the eyes of the potential users or buyers also fuels the urgency behind squeezing in the features. This a classic dilemma for products today.

Per the standard practices prevalent in product engineering today, the standard practice is to classify the features to be developed into different Priority Buckets along a scale. e. g. Priority 1, Priority 2, and so on. This scale may vary amongst various product groups. However, broadly this scale typically gets classified into three kinds of buckets – “Can’t go to market without them!“, “Lets do it if we have time!” and “Forget about it right now but I am so glad you documented it!“. Once the features or the requirements are classified in this manner, as a standard practice it is typically a race against time to see how many of these can be implemented.  If the team is able to implement the most from this list – they are considered to be the most efficient. It is also assumed that the product is better off once most number of the features from the list gets implemented.

However, in my opinion and experience – there should also be another way to look at the feature queue. The requirements prioritization should also take into consideration to understand if there is a threshold beyond which any addition of features would start affecting the product in an adverse manner. This threshold could be from the perspective of count of features or the spread of features from functionality perspective. Features and functionality in the product are meant for empowering the end users to fulfill their needs with the maximum amount of ease. Beyond a point, the additional features can make this task more complex and may actually result in turning off the user from using it.

Every product needs to have a core value proposition and a defined user base which it targets to. In my opinion and experience, the tendency to squeeze in as many features as possible in the product is typically associated with both. It can mean an incoherent understanding of the needs of the potential user base or probably a sign of weakness in the core value proposition associated with the product.

Any features which needs to go into a product should be focused around the few key value proposition which the product has to offer and how to do that in the best possible way. Increasing the breadth of features may enable the product entrepreneur to fill in a check list associated with a long list of features and claim “we have that too!”. However if this comes at the cost of diluting the key messaging associated with the product – this may just might mean the doom for the product.

Any thoughts or comments are welcome!

Add to Technorati Favorites

Convincing others for Waterfall or Agile Methodology

June 27, 2008

A colleague of mine sent me this email today. He mentioned about the dilemma which one of his client was facing. I have pasted his email below (I have changed some of the names to respect the confidentiality)

Hi Manish,

I needed some help on projecting Agile as compared to water fall. PQR product is getting implemented at ABC and ABC’s project head Dorothy is facing some challenge in motivating her team to work in Agile way, especially when it comes to UAT. I think it’s becoming hard for her to convince that ABC’s users can continue part testing for features released in UAT. ABC’s user’s team is more comfortable doing QA when complete product is rolled out for UAT. This approach will hamper implementation dead line (before <Month> 08 end). She was looking from us some kind of presentation / stats which clearly explains benefits of Agile over Waterfall and give some stats (if possible) on failed big projects using waterfall and successful agile ones.

Can we get some stats / figures etc around this request?

Having been in similar situations in the past, I can certainly understand Dorothy’s challenge. While I did respond back to my colleague (please see below), I thought about posting this email as a blog post to see if any of the readers out there can help Dorothy with their experiences and metrics. Also, I am sure there would have been many in Dorothy’s shoes and wanted to find out what they did to overcome the challenge. Please feel free to add your experiences in the comments section below this post.

My response to my colleague –


Software industry is littered with examples where the software failures (by failure I mean that it was not able to meet end-users needs) have occurred. However, most of the time it is very difficult to say that the failure occurred because of waterfall or agile or any other similar methodology. IMO, failures are always because of certain risks which could not be mitigated at the proper time. This article at the link below shows a survey results which lists why project failures have occurred in the past. When you look at these risks, it is fair to say that Agile Methodology is better equipped to mitigate these risks as compared to Waterfall.

Coming to your point of metrics – I personally do not have the project failure/success metrics comparing Agile vs. Waterfall. I can certainly hypothetically speculate, however I do not think that is what Dorothy wants. If I can understand what she is trying to look for is to look for ways to mitigate the uncertainties associated with the implementation deadline. If she lists these risks down and plans to mitigate that, she will very clearly see and convince people that Agile is probably their best bet.

I am slightly going on a philosophical note here – unfortunately we engineers many a times fall into a debate of one vs. other – Agile vs. Waterfall, Java vs. .NET, and so on as if they were two religions. I think achieving the goals is important as compared to looking at the rewards associated with selecting one vs. the other.

While I do not have a ready presentation on Agile vs. Waterfall (there are plenty on internet though which you can point to though). However, I would be happy to show and explain how we (in GlobalLogic) do it in Agile if Dorothy is interested. Also, please do note that the way there is ‘bad waterfall’ there is ‘bad Agile’ also 😉



As I said in my email, the success and failures of a project are typically not because of a particular methodology – but how the methodology helps to manage and mitigate the risks associated with any projects. There are good and bad implementation of all the methodologies out there. In my experience, it is not in the best-health of the project to get into the debate of goodness of one approach vs. the others. We should leave it to the ‘academicial-minded‘ to do that. The key is to take the best of all the approaches which would mitigate all the risks associated with the project.

Add to Technorati Favorites

Design/Development in Waterfall/Agile

June 22, 2008

I came across this post written by Kevin Barnes on Agile Processes. A slightly old post and I am not sure what exactly Kevin was trying to convey in this post. However, there was one picture on the same post which caught my eyes and to which I could relate completely.

Design/Development in Waterfall/Agile

(src =

The picture nicely describes how the two processes are loaded with respect to the Product Design and actual Product Development. Whether it is intended or not, there is typically a lot of upfront design effort in Waterfall. Whereas the Design process is more emergent in Agile. As they say, more important in Agile is the working code.

Add to Technorati Favorites

The Complexity of Status Reports

April 5, 2008

A colleague of mine and I were talking about one particular project where on average about 40 project/status reports were getting generated every week for management/team consumption. Both of us were astonished at this number. But the point which this colleague of mine made next was the real gem and hit the nail in the head. “What is the team trying to hide?

It is amazing to see amount of time being spent by many teams today in just generating the status reports every day or every week. And the complexity of these reports logarithmically increases as the whims and fancies of the managers. These reports today have simple views, side views, top views, bottom views, and multidimensional views – all possible views. There are graphs, excels, powerpoints, etc. Even after all these plethora of reports, one VP Engineering I had talked to, said that by the time she sat to review the reports, her biggest challenge became to make sure that everyone were looking at the same version of the reports. The reports review just became a secondary activity for her.

I am of the personal opinion that the day-to-day or weekly report should not stretch more than answering 4-5 simple questions. All the other ‘crazy’ reports which I alluded to in the above paragraph should be restricted to the ‘Retrospection Meets‘. (Assumption here is that the team is not doing retrospection meets every day or week. If they are that is another criminal waste of time.)

Over the years, I have always wondered why are we today so obsessed with seeing regular reports. Investors are keen in seeing the company financial reports, CEO is keen in seeing the attrition reports, Engineering Lead is keen in seeing the feature status reports, while a QA Manager is keen in seeing the Defect Reports. Hell, even parents are keen in getting regular status reports from their kid’s schools. The more I thought about this and talked to various people about their needs on this subject, there is one thing I have realized. The need for reports is not for seeing the past (i. e. what has happened in the past), but more from the need of seeing/predicting the future. Predictability is the main goal here.

When I think about any project status reports (whether it is a project for software product development or completing a press release article), the key simple questions which any day-to-day status reports should answer are (this is derived from Agile Philosophies) –

  1. [Effort View] How much have we completed and how much is still left?
  2. [Size View] How much have been produced?
  3. [Schedule View] How much ahead or behind are we against the planned?
  4. [Risks View] What are the things which are causing/or could cause a drag on the project?
  5. [Quality View] What is the quality of our output?

The challenge for the Project Management Team would be to see if they can answer these 5 questions in about equivalent number of or slightly more number of reports.

Thoughts/Feedback/Comments would be greatly appreciated.

Add to Technorati Favorites

Version 0.1 for Workstreamr

March 13, 2008

The team just released the first Iteration Release of Workstreamr this Monday and I was amazed at the terrific job they did. As I told all of them – this is probably the first time in my working experience that I have a seen a relatively functionally stable product released by the Development Team after the first iteration. Typically in my past experience, the first iteration release to the QA was when all the hell would break loose (sorry, there is a slight exaggeration here). QA cursing Developers for what they have handed them, Developers passing the buck to the Requirements Engineers for unverified requirements, and so on. It used to take few iterations and multiple patches to make the product stable for functional testing. In this case, the product was put to actual usage after the first iteration. It was a perfect synchronized dance between all the members.

The team sat down for an interesting retrospective meet yesterday.

Some key things which the team claimed worked very well for them were

  • Well defined and understood Iteration Goals. Goals were kept in an achievable format. (Team had spent substantial time at the start of the iteration to talk amongst themselves about the goals and success criteria)
  • Requirements in visualized formats (from wire-frames and prototypes).
  • Good team coordination and quick turn-around for queries. (Team uses Velocity Methodology & Platform)
  • Test Automation

Areas of improvement which the team suggested –

  • Branding Planning & Design should happen before the engineering starts.
  • In Iteration Planning Meets – plan for things beyond the next iteration.
  • Although it worked in the current iteration, Iteration Planning & Estimation process needs to be more rigorous.

There are three more iterations left for the release. I am sure the team would have excellent opportunity to implement these improvements. At this time, however, they should savor their achievements. And yes, a pizza is due on me!

Add to Technorati Favorites

Distributed Agile: Managing Agile in Distributed Teams

February 18, 2008

There seem to be an implicit assumptions amongst many of the Agile practitioners that Agile is best practiced in a small and co-located teams. I feel that in some sense these assumptions may be because the complexity of managing Agile in a distributed team/s (geographically distributed) is certainly more than practicing Agile in a co-located teams.

In my experience, managing Agile in a Distributed requires some special effort but it certainly can be practiced to a large extent. The major challenges comes in the face-to-face part – stand-ups, pair programming, etc. However, these challenges can be overcome by proper supplementation of roles, methods, practices, and tools.

I have captured my thoughts associated with how the complexity associated with practicing various Agile Values in a distributed environment can be eased in the table picture below.

Managing Complexity of Agile in Distributed Team

Managing Complexity of Agile in Distributed Team

The table above is self-explanatory. As you can see, to implement some of these values in distributed teams have the same complexity as in co-located teams, while in some the complexity of the practicing these values can be eased by proper usage of software engineering methods (my definition of a ‘Method’ is a combination of roles + habits) and some good tools. However, there are some practices of Agile (e.g. collaboration amongst teams is a big one here) where inherent culture and core values of the distributed team plays a key role.

On the side note – the term “Distributed Agile” can be confusing sometimes. For many who I have talked to, for them it appeared that they thought it was a new avatar or flavor of Agile. Distributed Agile is practicing Agile in distributed team/s. Simple!

Add to Technorati Favorites

agile vs. Agile

January 7, 2008

I have become a big fan of Agile Methodology over the last few years. One of my responsibility in my current organization is to practice, preach, and eat my own dog-food about anything associated with Agile. When I talk or work with many while doing this, it amazes me as to how much mis-conceptualized Agile is. Majority of whom I have talked to claimed that they fully understand it, yet almost all of them could not point out the core values around it. This is when the ‘Buddha’ moment realized on me! Majority of them who said they understood Agile really were referring to agile (with a small ‘a‘). For them fast and continuous change, quick turn-around, being nimble and flexible for anything was probably the core of what agile really meant. However, this can probably be termed as verb‘ial understanding of Agile. Agile (with a capital ‘A’) is more than that. It is more of a philosophy or culture or set of beliefs like the way we all think about ‘Hinduism’ or ‘Christianity’ or any other religion/practice out there. Key behind adapting Agile is to understand the core beliefs that have set the foundation of Methodology. The beliefs and practice of these key principles is what is needed to use Agile Methodology for Product Development.

So next time when you say that you are keen in adapting Agile, take a minute to think if you would like Agile to be served to you with capital ‘A’ or small ‘a’.

Add to Technorati Favorites