Posts Tagged ‘agile development’

White Paper on Design for Hybrid Agile Adoption

Wednesday, October 27th, 2010

In order to deal with these recent changes new software lifecycle models have emerged that promise to keep pace with the industry. Agile is one such emerging methodology that is providing: better project transparency, better requirement trade-offs, faster time to market, and improved quality and reduced defects. While Agile approaches have clearly seen judicious success in recent years, these have primarily been associated with collocated teams. Unfortunately, collocation is not an option for all Agile teams. In fact, collocation is an approach which, in some cases, has moved the industry paradigm decades back defeating the overall advantages and cost controls of off-shoring and out-sourcing.

Overcoming these challenges, “Design for Hybrid Agile Adoption (DH2A)”, is a framework defined to successfully execute agile projects in a distributed and out-sourced environment. Read More…

The Specialist versus the Generalist in Agile

Tuesday, February 9th, 2010

This contribution came from one of our regular writers – Venkatesh Krishnamurthy.

The topic of Generalists Vs Specialists is another eternal debate in the Agile community. Every one in the community has their own opinions. I too have my personal opinion about this topic.  Let me start this discussion with a few definitions.
Put it in a simple way,

  • A Specialist is some one who knows a “bit more” about something. In the context of the software world, this something could be Architecture, User Interface Design, Testing, Coding, Business Analysis, etc
  • A Generalist is some one who knows a bit about many things.

The question arises, should we have specialists in the team or generalists in the team.   Each of these techniques has its own pros and cons as explained in this article.

My opinion is that, every individual is passionate about something.  Sometimes they get to express it and get the opportunity to pursue the same, but many won’t get this chance.  People pursuing their passion end up becoming true specialists.  However at the end of the day, every one in the software company gets a designation whether they like it or not, and end up becoming specialists.

Is there a problem being a Specialist ?

Many Agile evangelists say specialists are not good.  However what they mean is bottlenecks created due to specialization is not good. Bottleneck arises due to demand and supply issue in the organization/project.
Let me give you an example, most of the software companies (that I have seen so far)  have limited number of  Architects and Database administrators and mostly these roles are shared among various projects.  Consider a situation when the Oracle DB admin who is currently been assigned to a new project is at the client site gathering requirements.  At the same time, a critical bug was detected in one of the DB modules that he worked on an earlier project and this is a show stopper.   This is a challenging situation right ?   How can we make use of the DB admin in handing this situation as he is the only one available.

Let us review couple of options on hand

Option 1:

Pull the DB admin for a few weeks from his current assignment and reassign him to the defect until it is fixed.   But doing so might make the current client unhappy

Option 2:

After completing the current assignment, go back to earlier project, understand the defect and fix it.  This may not be possible as the defect is critical and needs immediate attention

Option 3:Split time between the current requirement gathering work and fixing the defect.   It has been proven that  multi tasking reduces efficiency and productivity.

Situations like the one mentioned above where the specialists have become bottlenecks have made the Agile thought leaders encourage generalized specialists.

How to build Generalized Specialists ?

While I coach teams, I observe that if specialists are going to be shared across projects and by this I know that in the future they would end up becoming bottlenecks.  In such instances,  I apply what is called “Backup Pattern”.  This pattern name is my own invention.  While applying this pattern, I start analyzing the skills and passion of various team members and start making each one back up for the other.   This provides an opportunity to have backups (in knowledge and skill) and over a period of time, these backups will be in a position to handle most of the specialists tasks.   However the same backup personnel  would continue to have their own specialization.  The team members could volunteer to be backups.
Here is an example of a table showing my backup pattern technique

Module Name Skills/technology Primary Backups
Billing JSP, Java, Hibernate Rashmi Rohit, Chandru
Dynamic IP Generation Java, C++, Tcp/Ip Jim Chandru, Rashmi
CMTS configuration WAS, TCP/IP, REST, XML Chandru Jim, Rohit

Above technique has helped me in tackling the issues of specialization.  This is not a quick fix, and it takes any where from couple of weeks to months to build a generalized team.

Having an extreme form of  all Specialists or Generalists is not healthy for any project.   There should be balance between these two types  and decision to have generalists or specialists should be based on specific context.

Role of the Scrum Master – Dealing with Conflict Avoidance Teams

Tuesday, August 25th, 2009

This item was forwarded by regular contributor Venkatesh Krishnamurthy.

Have you come across teams where only a few speak and the rest listen?  Have you seen any of your team members not sharing their thoughts or participating well during Scrum meetings, retrospectives or other activities?  Have you come across any team where there is no conflict ?
Silent Teams
I would call teams where you don’t see conflict “Silent teams”.  For the sake of this article they are silent in speech, but not really silent in their mind.  The people in these teams are like any other people but all their questions, frustrations, arguments everything is happening in their mind. They never speak up or discuss things in front of a group, especially if their ideas conflict with others.  But there is the chance that they go and share their frustrations with someone closer to them in the team during the cafe breaks or with other close friends.

Why does this happen ?
According to Conflict Avoidance hurts Business… Individuals stay silent because….

  • We are afraid others won’t like us if we speak up
  • We fear the other person may say something worse about us
  • We wait until we’re really angry and fear loss of our tempers
  • We lack the skills and confidence needed to resolve conflict

Basically our identity getting hurt plays a key role here.

According to Ester Derby, Groups that avoid conflict won’t be able to face tough issues or handle the creative conflict that generates new ideas.

It has also been found that culture in certain Asian countries like Japan, China, Korea, India, etc have a Conflict Avoidance Culture. People in these countries are ready to keep silent during conflicts so that it does not hurt the other person or as Craig says they remain silent to create “Social Stability”. Scrum Masters, especially from these countries need to be conscious of, and ensure that conflicts are identified, brought out in the open and resolved. The team should be taught how to resolve them among themselves. Such teams tend to become self organizing much faster as compared to the conflict avoidance teams.

Here is a case study in which the team conflict avoidance led to a drop in productivity. ..

An onsite customer was very brutal with the offshore development team members. Every day he used to pick one of the team members and shout at them. Every day the conference call with the onsite customer was like attending a court where each team member was supposed to defend their work and explain what they did every hour of the day. The communication with the customer had always been one way.No discussions were encouraged. Even though everyone in the team was fed up with the customer, no one had the courage to speak up and confront him. Every day after the call, the team used to wait until the customer dropped off and then used to talk behind his back. Over a period of time the frustrations and stress lead to a huge drop in the productivity for the team.

Does this sound familiar to you?

Situations like these are all too common in organizations. As per Conflicts and Trust,

“Fear of what might happen if conflict were confronted causes otherwise proactive people to hesitate, and the cost of this hesitation is significant.”

Consider the cost of all those developers as their performance is dropping.  The unresolved conflicts keep accumulating in people’s mind and causes a huge hit on performance.

It is very important for the Scrum master to observe and understand the team dynamics. Craig Larman recommends Scrum masters ask questions like:

  • Are members avoiding discussion?
  • Is something hidden?
  • Are members truly committed to the team?

Managing Conflicts
There are techniques to manage the conflicts.  One of the most popular techniques is the Ladder of inference.

Role of Scrum Master – Dealing with Conflict Avoidance Teams

Need for the Right person to drive Agile Adoption

Tuesday, July 21st, 2009

The following comment comes from one of our regular contributors, Venkatesh Krishnamurthy.

It is very important to identify the right person to drive Agile adoption in an organization, rather than randomly choosing some senior person to drive it.

The reason being, Agile is all about

  • People
  • Being Flexible
  • Being Patient
  • Open to new ideas
  • Learning

Recently in one of the stories I heard, the CEO of a company who had been hearing a lot about Agile, decided to adopt Agile in his organization.   He decided to form an Agile Research Group to drive Agile adoption in the organization.  He choose one of the most senior Vice Presidents (VP) to drive this initiative.  He in turn choose some senior and mid-level managers to start gathering info.

Just like any company, the Agile core team started meeting weekly.  They started an Agile discussion forum and started gathering as much information as possible.

After a month of starting this Agile group, the core team submitted their findings to this Vice president.  After few days the VP called the core team for a meeting and the team couldn’t  believe what they heard from the VP.

Cutting a long story short, the VP didn’t believe that there existed concepts like Iteration, Daily Stand up meetings, self organizing team, Iterative and Incremental development approaches.  He didn’t believe the reports submitted by the core team.  In this situation, the VP himself became hindrance to the Agile adoption.

This may not be the case in all the organizations, and it could be a “one off”, however it is very important to choose the right person for any new initiative – especially when it comes to Agile adoption.

In another case study, the CEO of the company appointed a senior person from the Quality group to drive Agile adoption.  This Quality group head was coming from a strong CMM and Waterfall background.  The team assigned to try Agile on a sample project used to read books, attend trainings and try the practices on their projects.
Many a times this Agile group failed in implementing the practices, but each time they failed the senior person driving Agile, used to tell them “I told you Agile won’t work’ or used similar kinds of statements.
Such statements discourage the team.  One has to remember that, It is normal that the team might fail while implementing new practices, and in such situations “Patience” is the key.

I believe that the following attributes should be expected from a person driving Agile

1. Good understanding and knowledge of Agile
2. Be open to new ideas
3. If the team fails somewhere, analyze the situation and encourage them rather than pushing them down
4. Trust the people around him/her
5. Patience
6. Persistence

Remember that  the wrong person in the right place could not only become a bottleneck for Agile adoption but also could lead to failure of the implementation of Agile.

Identifying a Scrum Master for a new Scrum Project

Friday, March 13th, 2009

Another contribution from Project Perfect regular contributor Venkatesh Krishnamurthy.

We know that the Scrum Masters should posses the following skills to be effective in their roles:

  • Be a sheep dog, ensuring that the team follows the Scrum Practices properly
  • Be a servant leader
  • Impediment remover
  • Be like a parent – Take charge if the kids are going in the wrong direction.
  • Avoid command and control mentality.
  • Good facilitation skills
  • Communication and Negotiation skills: Even though these two skills are mandatory for any team member, I thought of explicitly bringing this out here.

I feel that above skills cannot be acquired through trainings or bootcamps and not even by reading books.  However one could acquire the above knowledge through various sources like books, trainings and attending seminars.  In order to really implement them and make it a part and parcel of life, would require dedicated practice over a period of time.

If we come across a person with the mastery in above skills, then he/she would have had:

  • A lot of experience in dealing with various situations
  • Experience working with in a multi cultured environment
  • Experience in making tough decisions under various circumstances and specifically the ones related to management

Even though imagining a person with above skills might create a picture of a serious person, I don’t mind adding another point to the above skill list as “Light Hearted”.

I have also observed that the most of the above skills are found in senior(experienced) people in the project as they would have gone through implementing projects in various capacities.

Now coming back to the actual point, if your project is transitioning from waterfall to Agile (Scrum), can you pick one from the existing waterfall team to be a Scrum Master?  It is a tough decision.  Even though there is no rule around “seniority” of a person to be picked as Scrum Master, I have observed in most of the projects that the senior most person in the team, typically posesses “some” of the above skills and it is mostly the Project Manager.

Many “waterfall to Scrum” projects typically would pick the “Project Manager” to be a “Scrum Master” but where they fail is in identifying the missing gaps in the skills of the Project Manager that stops him becoming a true Scrum Master.  The “Project Manager-Scrum Masters” continues with their old PM skills and never become a true Scrum Master and thus the project never achieves the desired results of a true scrum project.

Since, the Scrum Master need not posses deep software and technical skills, I don’t mind recommending someone from a non-software background for this job.  I have seen that many great leaders come from a non-software background.