The myth that Agile methods, in particular Extreme Programming, are a -product of and for a small group mostly white, mostly male and mostly staying in Silicon Valley [US], has begun to do the rounds. According to the same group of critics, Agile is a movement that is based on the fact that [white male] people would be working with people like them, don’t want to be accountable for the results and want to have no allowance for slower mortals. In short, their criticism is centered on the fact that Agile does not support diversity or that it is just a cover up job on bad habits of predominantly male techies and that all techies would be alike [read male, predominantly white in California]. The last two of these argument are provided as a backup case to highlight that Agile does not support diversity.

Agile does not support diversity: This is so way off the mark that you don’t even know where to start. You routinely hear stuff like “Agile is not a silver bullet“, “Agile would not work with incompetent people“, “Agile values each persons contribution“, “Agile is about working together“, “Agile is about defining what works best for you” and “Agile is about constant improvement and learning“. Agile is perhaps the only framework which specifically says - just because it worked somewhere, does not mean, it will work for you. Also, Agile does not give you a complex “how to” for every situation. It simply asks you to orient and train yourself to handle emerging situation and knowledge. It seems like it is a good idea to go back and revisit what Agile is:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The principles behind Agile Manifesto are also explained. Its not to suggest that other methodology or frameworks do not value these principles, but that “Agile” values them as well. This established, lets do a chronicle of where Agile has worked the best:

• Norway has the highest density of CSMs
• Companies across India are embracing, training and converting to Agile/ Scrum
• Thoughtworks - one of the earliest leaders in Agile Software Development has offices across the world and only one in San Francisco
• At our end in Net Solutions also, we have not identified any pattern to see if women or freshers performed poorer in Agile projects - in fact they have generally done better [like everyone else]
• Mary Poppendieck is one of the thought leaders of Lean Software Development community, which shares much in common with Agile

Hence, the argument that it works only or for in Silicon Valley with [predominantly white] male population is not correct. And people who make these claims are doing so based on their understanding of what Agile is. Inherently, Agile is based on a simple premise that effective software development is not just a function of tools used but also practices employed. AND it says the best teams are ones which can decide for themselves how to manage themselves and are aided by effective technical and marketing leadership. A more serious argument against self organizing teams is that a group majority or camps would come up. One way to answer this is that these camps come up anyways. However, if you review Agile principles further, then its clear that Agile values team spirit, collaboration and if the group majority or bullying stops other participants from participating effectively, then there is a problem but the problem is not Agile or Scrum. Lets try and use the root cause analysis for the same:

• Why are some people bullying or forming sub-groups? Possible reasons can be:
  • They don’t think others are good enough
  • They think too highly of themselves
  • They don’t want others to progress
  • They don’t like someones face
  • They don’t like the rude manner in which some people talk

Even at a very basic root cause analysis Level 1, one can see that the problem is not Agile but something else and Agile would only make that visible. One of the solutions for this could be to have someone at everyone’s head almost as a referee/ arbitrator/ disciplinarian. Thats how traditional management would usually approach this problem. However, this is more of a problem kept under control strategy rather than problem solving. Agile Leaders and coaches would approach the problem differently. They could ideally bring this topic in a retrospective discussion, throw it open for the team and discuss ways and self commitments for this. If we take the above Level 1 root cause to Level 2 and as Why for each of the above questions, we would probably get this answer “Everyone is competing with everyone else and themselves.” Hence, some others could train using analogy and work with each of the team members on specific collaboration skills - fostering collaboration rather than competition. Some coaches and leaders could use games and simulation exercises to get people out of standardized, conformist and single dimensional learning imparted by most schools and universities. As one can see, Agile is formally valuing and practicing collaboration.

How could formally valuing and practicing collaboration over lone-wolf, gold-plated, 24×7 hero-programming not support diversity. In fact this does the exact opposite - promotes diversity.

P.S. And yes its not a tech equivalent of Beach Boys.

Popularity: 12%

Posted on January 24th, 2008 by pamela.sahi
Filed under: Myth Busters, Values | 1 Comment »

Agile is an iterative and incremental development process. However, the fact that you are doing iterative and incremental software development, does not necessarily mean you are doing Agile. It is often useful to see the relationship between iterative and incremental development [IID] and Agile through a venn diagram. A common fallacy is to see the relationship as below:

This is not entirely correct. Considering any iterative and incremental development process as Agile is misplaced. Agile is an iterative and incremental development framework but there is more to Agile that just iterative and incremental development. A brief overview of Agile has been presented in the Agile Manifesto. Doing iterative and incremental development does make you more responsive to change, increase customer collaboration and even deliver working software at the end of iteration. However, it is possible to do iterative and incremental in a manner that is anti-Agile. To achieve agility in your development process, in addition to an iterative and incremental development you would need:

• Agile conforms process to people and stresses on a self organizing team. This is perhaps the most important distinction. Agile does not view people as “resources” or “nuts and bolts” or “puts process on top of individuals”. A self organizing team would choose the process it needs based on experience and current situation. This is possible only by creating a culture of decision making, team collaboration, customer collaboration, continuous training and learning. An iterative and incremental development process ridden with ceremony and processes is anti-Agile.
• Agile stresses on collaboration. Tools are there to help you achieve a goal and are not a goal in themselves. A self organizing team could choose to only use notepad while another could choose a million dollar IDE. However, the teams would be collaborating towards a common goal at the end of iteration and not individual targets or productivity. In addition, Agile stresses on customer collaboration beyond just doing iterative and incremental development.
• Agile is adaptive and emergent. The fact that you had a nice plan upfront on what each of the increments would be and exactly how iterations would work, and the project was run exactly like that, is not Agile. This could be possible in some projects [shorter duration, one which you have done many times], but in most projects this is a clear indication that Agility has taken a hit [either of the customer collaboration or product owner feedback loop would be weak]. Ideally, you would want the project to adapt based on emerging requirements rather than stick to an iterative and incremental plan.
• Finally, Agile is about useful working software. At the end of an iteration, working software has to be provided. It is useful to consider Scrum notion of “potentially shippable code”.

As can be seen all the four aspects above aid each other. For instance, the fact that you focus on useful working software makes the project adaptive to emergent requirements which is possible only in an environment of customer collaboration. A self organizing team would be in a better position to provide useful working software quicker and better through better internal team and customer collaboration.

Hence, a better relation between IID and Agile would be as below:

IID + [Agile Values and Principles] = Agile

Also, a better Venn Diagram representation of IID and Agile would be as follows:

Popularity: 20%

Posted on January 6th, 2008 by admin
Filed under: Introduction, Myth Busters, Values | 1 Comment »