Need for Retrospectives

Every organization and every project has some grapevine running in the inner circle. When I say Inner circle,

it is the closed group of people who trust each other.

For ex: In a typical software project,  a manager(PM) with command and control attitude, would encourage creation of inner circle with project team members, whose opinions are being ignored by the PM. This inner circle group  excludes the manager.  This group in turn talk among themselves and share their agonies without the knowledge of the manager.

Above example of team member inner circle group, can be extrapolated at an organizational level with inner circle being the employee group excluding the management of the company.

The inner circle groups mentioned in the above examples are harmful for the project and the organization. They get created as they don’t have any venue to express their bottled up emotions/thoughts/opinions. This in turn leads to a lot of negativity. This negativity needs to be conquered sooner than later. Here is a good article, which provides techniques to conquer such negativity.

One of the ways to conquer the negativity is to provide a platform for the employees to express their thoughts/opinions/emotions. In Agile projects, retrospectives provides such a venue. This in turn leads to healthier project and teams in a longer term.

Difference between Sprint and Iteration

“Iteration” is commonly used to term in all Incremental and Iterative development methods. 

However the word “Sprint”, which has similar meaning to iteration was coined in the Scrum method. Mostly the Scrum practitioners use the word Sprint. Even though many people use the word Sprint and Iteration interchangeably, there is a notable difference between the two.

Sprint as defined in pure Scrum has the duration 30 calendar days. However Iteration length could be anything as defined by the team.

Introducing new concept – Innovative way from Google

Bringing change is not easy, and people resist changes. Top ten reasons why people resist changes can be found here. Nowadays new processes and technologies keep getting invented everyday and the employees need to be up-to date with it to be competitive.

Introducing the new concepts is not easy. Thought leaders have come up with several patterns too to introduce changes in the organization.   However recently I came across this article Testing on Toilet, which talks about the innovative way being used in Google to teach their employees testing and bringing new change.  As per the author,

A regular weekly(ish) tip posted in toilet cubicles and above urinals. Short enough to be read whilst doing your business

Even though the above method looks odd and radical, trust me at the end of the day, developers would definitely learn something good and remember it for a long time.

Here is one of the actual pictures taken in the Google toilet giving some tip about testing certification

Agile Certifications

Suddenly I am seeing a spurt in activities around Agile certifications. Scrum Alliance is working seriously with various thought leaders in coming out with new certification criteria.  There is another organization World Agile Qualifications Board(WAQB) coming up new Agile certifications.

Hope all these people come together and have one certification at some point of time in the future.

Glossary of Scrum terms

Scrum being the most popular Agile methods, a lot of new Scrum users either are getting distorted definition of many Scrum terms or have total misunderstanding of the terminologies. 

To avoid such misunderstandings, Scrum Alliance has glossary of 39 key Scrum terms

Scrum FAQ

Following questions are frequently asked by the novice Scrum teams. I will keep updating these questions and answers as and when I get it.

1. Can we have single Scrum Master(SM) for multiple projects ?

Answer: It is recommended to have a dedicated Scrum Master for each project. Diluting this could also dilute the effectiveness

2. Can Scrum Master be a Product Owner ?

Answer: Scrum Master should never be a product Owner.

3. Can Scrum Master be technical and can SM help the team if they are stuck with technical issues ?

Answer: It does not matter if the SM is coming from technical background or management. However if SM is technical, he/she should be careful enough not to dilute the SMs responsibilities in the process of helping the team with technology stuff.

4. During the Scrum Meeting, my colleague talked about an impediment and I had the answer. However, can I answer it immediately and it won’t take more than 1 minute ?

Answer: Don’t diverge from the recommended rules around Scrum Meeting. Any discussion should happen outside the Scrum Meeting. Even though your answer takes only one minute, some one else could also jump in saying even he/she needs a chance to answer another question. This leads to chaos and could stretch Scrum Meeting beyond recommended limit of 15 – 20 minutes. My recommendation is to follow the rules by the book until every one gains experience.

5. I just need another 4 hours to complete my task and the iteration is coming to an end, can I stretch the Iteration/Sprint duration ?

Answer: No. Iterations are time boxed.

6. When people say Sprint duration is 30 days, is it working days ?

Answer: Sprint duration of 30 days means 30 calendar days.

7. The team has completed all the tasks before the sprint ends, what should they do now ?

Answer: The team can approach the product owner and request for additional items from the PB.

8. Is it mandatory for the team to follow the Idealized line in the burn down charts ?

Answer: Idealized(A.K.A Ideal) line provides just a point of reference.

9. Can I work on the undone tasks in the next iteration ?

Answer: Undone tasks would go back to Product Backlog and Product Owner would make a call on the set of requirements for the next iteration with due feedback from the team.

10. Should I use Iteration or Sprint ?

Answer: All sprints are iterations but not all iterations are Sprints. Sprint is the terminology coined by the Scrum co-founders to define an iteration.

========================================

P.S: If you are aware of more questions and answers, feel free to send me and I would post it here.

Getting the estimations "accurate" in one go – a vestige

A team adopting Agile method for the first time tends to do many mistakes during the initial days. One of the common mistakes is about trying to do accurate estimation. During the Iteration Planning Meeting(IPM) of the first iteration, the team does not know their velocity and tends to spend time trying to come up with “accurate” estimates or estimates with additional unscientific buffers. They tend to spend too much effort detailing out tasks and estimate them.

Agile methods discourages teams spending too much of effort on reaching perfection in one go, especially around estimations. It recommends teams to apply the empirical control model by frequently inspecting the estimations and adapting them.It recommends to go with daily re-estimation technique.

Daily re-estimation

Agile methods recommend that

• During the IPM, estimation for the requirements should be done with whatever knowledge one has at that point of time
• While doing the daily re-estimation try to steer and come up with more accurate estimates
• Use the optimistic estimates rather than the pessimistic estimates

Subsequent Iterations

Right from the first iteration, the team must track couple of key parameters, For Ex:

• Planned effort Vs actual effort
• Number of committed stories Vs actual stories delivered
• Number of new tasks discovered during the iteration
• Planned resource budget Vs actual resource budget

Once the team gets to know their velocity, the future iterations could be estimated and planned in a better way.

Conclusion

• Trying to detail out all tasks, trying to provide accurate estimations, detailed planning and analysis are the vestige coming from the waterfall model
• Agile recommends frequent delivery of working software rather than wasting time on analysis-paralysis

Potentially Shippable product – A Myth or Reality ?

 

Scrum defines that, at the end of each sprint potentially shippable product (PSP) should be ready. 

Ken defines this product as

Sashimi, a thin slice of product which contains all aspects of the product

Let us closely watch the iterations/sprints happening around us and  do you see a sashimi kind of product at the end of each sprint ?

I have not seen many  …

Most of the times I have observed that the sprints end with all the features being coded but testing, defect fixing spilling over to next sprint. This results in not having a potentially shippable product. There could be many other reasons in addition to the above but time and again, Agile projects end up with incomplete sprints and that is the reality.

You might ask, if each sprint ends up with an incomplete work, when can we see a stable product  ?

Answer is the work around invented by the thought leaders. It is called Stabilization sprints.

What are stabilization Sprints ?

These are sprints dedicated towards tasks such as

Defect fixing
Fixing technical debts
Completing any final rounds of testing
Update or fix any architectural issues
Getting ready for the release by completing release notes, etc

Stabilization sprints can be scheduled based on the need of the hour. There is no hard and fast rule around when it should be scheduled.

Many people call stabilization sprints with different names based on the specific activity being executed. Some names are, Testing Sprint, Technical Debt sprint, Analysis Sprint, etc

Is it a right approach to have stabilization sprints ?

Some people believe that Stabilization sprints are Scrum’s Anti Patterns. The suggestions given at various places to solve this anti pattern is to define Done properly. The product owner is expected to set the right expectation for the team during the planning meeting through Done.

Conclusion

• It needs a lot of discipline to deliver a potentially shippable product during each sprint. 
• Even though stabilization sprints are not recommended, it seems to be the reality

Continuous Deployment – What is the limit ?

I have heard about project teams still coming upto speed on daily builds and many are still living with nightly builds. 

For many continuous integration is still a dream. It is a proven that practice like building and testing the code continuously helps to improve the ROI in the long run. 

What about Continuous Deployment ? How many times a can you deploy ?   Even though setting up build and continuous integration is one time effort, it is the discipline that makes the build and continuous integration process to work.  If you want to learn about such a disciplined system,  read how the continuous deployment is done fifty times a day at IMVU from here

Need for matured developers in Agile Teams – A Myth

I have heard many times from in-experienced scrum coaches saying Agile projects need matured team members. The Big myth The above statement is as big a myth as the one which says Agile projects follow no documentation The answers I got… I had asked one of those in-experienced scrum coaches the following questions,   What do you mean by Matured team members ?    Why do you think Agile projects need more matured team members ? The answers surprised me a lot, the answers were    Matured team means, a team with more experienced people      The reason we need matured teams is because, concepts like self organizing teams and self managing teams are easily understood and implemented  by experienced developers as compared to juniors. They also say that the junior developers mis-use the freedom and trust shown in Agile projects and so, they are not suitable !! Does maturity comes with Age ? My view is, maturity to a person does not come with age or more experience at work.  Secondly, concepts like self organizing and self managing teams need the fundamental value, trust to succeed than any software development skill or experience. I strongly believe that, individual team members shouldn’t be blamed. This is because, the culture followed within the team is strongly influenced by the person leading the team. According to the greatest thinker, Peter Senge, We must look beyond individual mistakes or bad luck to understand important problems. We must look at the underlying structures which shape individual actions and create the conditions where types of events become likely So, if a junior team member is not doing his/her assigned job, instead of blaming him/her, we should look at the system which is driving this character within them.

Conclusion

Success of Agile projects does not depend on the experiences of the team members but on the fundamental value driving the system.

Key Do’s and Don'ts in Scrum

 

Even though there are several  rules and practices in Scrum, but still they don’t  cover all contexts. Practitioners keep coming back with several questions like,

We don’t have a scrum master yet, can we   make the Product Owner as the scrum Master ? Can we have a single Scrum Master for several projects ? and several others ….

So, here are some of the answers to questions like the ones mentioned above 

Here are some of them

• Scrum Master ideally should lead only one team and the same thing applies to Product owner.  If they are leading more than one teams, their effectiveness decreases by the same fold
• Don’t let Scrum Master to wear the cap of  product owner too
• Don’t let one of the team members to take the role of Scrum Master
• Even if there is a large team, ensure that there is a final product owner making final decisions about the product backlog
• When Scrum says, team size should be 7 +/- 2, this number does not include then Scrum Master and the Product Owner

Technorati Tags: Scrum,ScrumMaster,ProductOwner,7+/-2

Test your knowledge on Scrum

http://www.freedigitalphotos.net/

Ken Schwaber, co founder of Scrum has come out with an online program to assess Scrum Knowledge. This assessment checks purely "What" scrum is all about.

Here is the link to the program with the password

http://www.scrum.org/scrumassessment/

password : "assessment2"

Agile and Model of Concurrent Perception

Dr. Rubinstein is professor of engineering and applied science at the University of California, Los Angeles, has written articles and books on Concepts in Problem Solving and Tools for Thinking and Problem Solving.

As per Dr.Rubinstein's model of concurrent perception, if we start with trying to keep the order from the beginning it leads to Chaos at the end.

For example, in traditional waterfall model, the stakeholders try from the beginning to keep order by

• trying to gather all the requirements and freezing them
• creating project plan written on stone with exact dates of release and delivery
• building the design and architecture and freezing them

Since there is no room for a retrospection at any time in between, the traditional waterfall model leads to chaos at the end with the delivery of the poor quality product, missed deadlines.

Dr.Rubinstein, suggests that try to have chaos as much as possible in the system. Chaos here, does not mean a havoc/uncontrolled nature, but a sense of openness to receive feedback.

Dr.Rubinstein quotes the example of car manufacturing. Before building a new concept car, engineers from various departments are invited for a discussion and their views are taken. At regular intervals, feedback from respective departments are taken, even if it leads to many changes to the design. The system which is open for changes in the beginning, ultimately ends with Order.

If we look at the recommendation from the above model, i.e. have chaos to have order , don't you think this is where the principles of Agile fits in ? .

In case of Agile, the chaos stays in the system by virtue of practices like

• Open to receive new requirements at any time
  
• Collaboration with the customer on a daily basis and open to receive feedback
• Self Organizing and Self Managing teams as opposed to command and control
• Weekly review and demo for the customer to get feedback
• Retrospectives at the end of iterations to learn from past mistakes and plan for the future
  

Dr.Rubinstein says

concurrent perception feeds vitality, while sequential perception saps it

Agile Project Management Tools

During the early days, while Agile methods popularity was still at infancy, there were hardly one or two project management tools that catered to the needs of Agilists. Nowadays, I hear atleast a new tool almost every other week. I thought let me list them out here.


The following list has both Open source/freeware and commercial tools and the listing is not in any particular order.


1. Rally
2. VersionOne
3. XPlanner
4. Extreme Planner (Don't get confused with XPlanner mentioned above)
5. Mingle from thoughtworks
6. TargetProcess

OpenLogic in turn has done a nice work of comparing the following(7 through 10) 4 open source Agile PM tools
7. AgileFant
8. IceScrum
9. Agilo
10. eXplainPMT
11. SilverCatalyst
12. GreenHopper with JIRA
13. Agilebuddy
14. WoodRanchTech
15. PivotalTracker
16. BrightGreenProjects

17. XPlanner+ (Thanks Sezam20 for referring this tool)

Additional Information
You can also get additional details for some of the above tools from here.
Mike Cohn maintains the list of Agile PM tools here . (Thanks Phil for sharing the link)


Feel free to share the names of any other Agile PM tools that you might have come across and is not present in the above list.

Applying Pomodoro technique during Pair Programming

What is Pomodoro ?
Recently I learned a technique to improve the productivity and efficiency of my day to day activities. This technique called Pomodoro technique is not a new one, however I have rarely come across people practicing it. It has been two days since I learned this technique and started practicing it, trust me, it is a life changer.

The 5 minute overview of this technique could be found here. Interesting thing I found about this technique is, it has some of the characteristics of Agile methods.

To name a few,

• Time boxed Iterations
• Review at the end of the day and feedback to improve for next day
  
• Sustainable pace

Applying it on Pair Programming
I also found that this technique could be used while pair programming. As we know, during Pair programming, one of the recommended practices is to change the pair's role once in a while. By applying Pomodoro during pair programming, one could change the roles every 25 minutes with 5 minutes break after that. Even though 25 minutes rule is just a recommendation, I felt that to begin with 25 mins time boxing is really optimal. More information about applying this on pair programming could be found here

The Challenge
During the initial pomodors, I found it really hard to work continuously without getting distracted, either mind comes with new thoughts , some work, etc or some one comes to disturb.

Software influence
The author recommends using Pencil, Paper and the kitchen timer (pomodoro) for tracking the sessions. However being a software person, it is tough to keep your eyes off the spreadsheet/word doc. I don't have a kitchen timer at home, however I am using a software timer to keep track of the time.

Scrum Vs Kanban fight

The fight between Scrum and Kanban is not over yet. Here is a nice blog entry that not only exposes the fight but a nice way to teach the intricacies of the two methods.

There are people who are proposing the middle path i.e. the ScrumBan path.

Agile Assessment tool

I am in the process of creating an Agile assessment tool. The assessment questionnaire would cover the following areas.

1. Fundamentals of Agile
   
2. Scrum concepts and practices
3. Engineering Practices
4. Workspace related

Fundamentals of Agile would cover questions around 4 Values and 12 principles of Agile

Scrum concepts and practices would have questions around 3 roles, 3 artifacts and 3 ceremonies. Specifically the team section would cover self organizing teams, cross functional teams

Engineering Practices section covers practices from XP (TDD, Coding Standards, CI, etc)

Workspace, as the name itself implies would cover topics like seat arrangement and other environment related topics such as use of Post-it notes, white boards, etc

The differentiating factor between the assessment tool that I am creating and other popular ones like NokiaTest is the granularity of the questions. Many Agile assessment questions that I have come across are at coarse grained level. I am in the process of creating fine grained questions.

According to me Questions like the following are coarse grained

• Do you do scrum Meeting ?
  
• Does your product owner prioritizes the requirement ?

Questions like the following ones are fine grained

• Do you ask the 3 questions during Scrum Meeting ?
• Do you do the meeting at the same place and same time each day ?
  

In the example above, the coarse grained questions around Scrum Meeting won't tell you if the team (specifically a novice Agile team) is practicing the Scrum Meeting in the right way.
The tool I am creating would ward off such differences in understanding of concepts and ensures to check consistent understanding of popular practices across the organization.

Choosing the Proxy Product Owner

Agile methods recommend having a dedicated Product Owner sitting with the team. However in practice, many product owners come up with various reasons for not being able to sit with the team.

(Image Copyright: All rights reserved by creator).

Some of the popular ones being

• We are very busy and don't have time
• We don't have sufficient budget to allocate a person
• It is the responsibility of the software company to gather requirement from us and understand it in one go
• Project is very large and single product owner is not sufficient to manage. But we don't have budget for multiple product owners (as experienced in distributed large scale development model)
  

We could add many more reasons to the above list.

However the software companies cannot or won't push the customer too hard on this front as they fear losing the customers. Keeping the above practicality in mind, some thought leaders have come up with a concept called Proxy Product Owners.

Identifying the Proxy Product Owner

The thumb rule many people propose is to make the Business Analyst(BA) the proxy product owner. This is because, BAs are considered to have in depth knowledge about the business and they can prioritize the requirements with little or no help from real product owners. They could also clarify any doubts around requirements as needed.

The question is, is this thumb rule applicable to all projects ?

Challenges in small budget projects

In fact, I believe we cannot apply the same thumb rule everywhere. Not all software projects have the luxury of having a dedicated Business Analyst.

How do we deal with situations like this when BA is not available ?

Many agilists propose an alternate idea i.e. to identify a senior developer or project manager as the Proxy. However I believe it is not easy as choosing a proxy based on seniority. The proxy needs to meet certain criteria for playing this role.

My experience says, to be proxies should have

1. built the trust with the product owner
2. faith from the team members
3. influence on the project team members and respected by other stakeholders
4. the ability to make decisions and convince others

So, it is very important to look at above and may be other key criteria before choosing the proxy product owner, otherwise, the project could get into trouble soon.

Cross Functional Team and Creativity

Recently I was reading the HBR article How Pixar Fosters Collective Creativity. Whether you know this or not, all the eight films released within a span of 13 years have been successful. I am sure you would seen atleast 4 out of these 8 films (A Bug’s Life; Toy Story 2; Monsters, Inc.; Finding Nemo; The Incredibles; Cars; Ratatouille; and WALL·E).

CEO of Pixar quotes that the reason for such a grand success is mainly due to Creativity in their team. He continues to say that,

Creativity involves a large number of people from different disciplines working effectively together to solve a great many problems.

If you carefully read the above lines, it is quite clear that, "people from different disciplines" is nothing but the cross functional teams as advocated by some of the Agile methods. It is also apparent that forming a component team with monotonic single disciplined team leads to failures, as compared to the multi disciplined Cross functional teams.

Role of Scrum Master - Dealing with Conflict Avoidance Teams

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
The teams where you don't see conflict, I would call them as "Silent teams" for the sake of this article are silent in speech, but not really silent in their mind. The people in this teams are like any other people but all their questions, frustrations, arguments everything is going only in their mind. They never speak up or discuss things in front of a group, especially if their ideas conflict with others. But there are chances that they go and share their frustrations with some one closer to them in the team during the cafe breaks or with any other close friend.

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 tried it before and things escalated or nothing changed
• 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 Conflict Avoidance Culture . People who are 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 open and resolved. The team should be taught how to resolve them among themselves and such teams tend to become self organizing much faster as compared to the conflict avoidance teams.

A Case study
Here is a case study in which the team conflict avoidance lead to drop in productivity. ..
An onsite customer was very brutal with the offshore development team members. He used to pick every day one of the team members and used to shout at them. Every day the conference call with the onsite customer used to be like attending a court where in, 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 every one in the team were 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 drops off and then used to talk behind him. Over a period of time the frustrations and stress lead to a huge drop in the productivity of 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 takes 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 to 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 too, one of the most popular techniques is the Ladder of inference.

Lean Primer by Craig and Bas

Recently, Craig and Bas have published a very nice primer on Lean software development. It is free and could be accessed from here

Inventing your own Light weight methodology - A Case study

In the past I had implemented a project by inventing my own light weight methodology and I am sharing my experience in this post.

Even though the inspiration came Agile values and principles, but didn't follow any specific methods like XP or Scrum as a whole.


Context:
1. "<5 " member team
2. Collocated team (dev team in India and technical SME in US)
3. Web application development
4. Team composed of members who are fresh out of college and in equal proportion experienced members
5. Team was well aware of the technology
6. The team members were passionate about learning the new technology and hard workers too.


I was an architect and also played a role somewhat like a Scrum Master.

1. Every day in the morning when the team had arrived, we used to sit in a circle and ask individuals plan for the day and if they need any help in resolving any issues. This could be compared to a scrum meeting except that we didn't ask the 3 questions nor we stood in a circle.

My observation is, it is not that the ceremony which matters but the values behind the ceremony that makes the difference.

2. When each team member used to speak out about his plan, I used to make a list of action items on a white sheet of paper. Let us call it as Action List.

If your team sits closely in cubicles and does not have access to huge team rooms, white boards or post-its, then the above method of writing on a white sheet of paper could help.

3. Many a times the onsite team would have done some review of the application and would have suggested changes through email. I would add them to the Action list

4. Once every one has completed sharing their action items and impediment list, they used to take a quick 10-15 minutes break and return back to work.

5. The action List was kept at a visible location so that everyone can see.

6. The team members used to glance through the Action list, depending on the priority (discussed verbally) they pick up the task and start working on the same.

7. After completing each task, they would come back to the Action list sheet, take a look at it, pick up one of the pending tasks voluntarily. As soon as they complete any task, they used to put a check mark on the same.

8. There was a progress review in the afternoon and at the end of the day another review on where we stand. It was more like a retrospective but without much rituals like +/Delta analysis or so.

9. At the end of the day before the team used to leave work, we used to quickly talk about the tomorrow's plan.

10. Informally the team used to discuss about the design, coding and other issues during the cafe breaks too.

11. As an architect I used to sit and code, and at the same time if any of the team member's are stuck then I used to jump in to help them out. If I can't help them, then I used to reach out to other experts through my contacts and get them the necessary help.

12. Estimation is done by the team. Since the team had experience with the domain and technology, based on past experiences, they used to come out with the estimates.

13. Couple of other good engineering practices include,

• Daily code reviews
• peer reviews
• Continuous integration
• Daily builds
• Regression testing using Selenium
• Unit testing using JUnits and EasyMock
  

14. Interestingly we didn't have a separate testing team, it was the developers responsibility to test it thoroughly and release it to the customer for UAT.

Above method that I had applied is a very simple one and does not have too many ceremonies attached to them.

This project was successful, team and the customer was happy.

The Semco Way

I had read Ricardo Semler's book, Maverick a few years back. Today I came across Semco's survival Manual on their site and is very inspiring.

As you read their list of values and practices, you could imagine the self organization and self management going on in Semco.

I highly recommend any one to read Maverick which inspires you to think differently.

Need for the Right Person to Drive Agile Adoption

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




The reason being, Agile is all about

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

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

Just like any other company, the Agile core team started meeting weekly, they started the 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 (VP). After few days the VP called the core team for a meeting and the team didn't believe what they heard from the VP.

Cutting a long story short, the VP didn't believe that there exists 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 case, the VP himself became hindrance to the Agile adoption.

This may not be the case in all the organizations, and it could be one "off" the case, however it is very important to choose the right person, especially when it comes to Agile adoption.

In another case study, the CEO of the company appointed a senior person from 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 kind 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 key attributes are needed in the person driving Agile Adoption

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

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

You could read this article also on Project Perfect blog

Have you come across such stories, you can share them here....

Interviewing candidates for Agile Projects

If you are running an Agile project and looking at hiring a suitable candidate, here is an excellent article which describes the step by step process of extreme interviewing.

Introduction To Lean

Recently I was watching the web cast on Lean Concepts for IT Professionals by Durnall and Parkinson. They have provided a very good introduction about lean covering its history and principles. It is an hour video and worth watching. While watching the video, I made some notes and here are some of them :

1. Mass manufacturing addresses the challenge of volume, where as the Lean addresses the challenge of variation

2. When volume doubles, economies of scale reduce cost by 15 - 20% per unit but costs go up 15% to 35% every time variety doubles.

3. Jidoka is all about automation. Humans are flexible but not good at repetitive tasks, however Machines are good at repetitive tasks but are not flexible. Jidoka talks about using both Humans and Machines to create a good system


4. In Ford the machines in the assembly lines are stopped around 8 – 10 times a day but in Toyota, they stop the machines nearly 27000 times a day. This is mainly because, each time any employee of the company finds a fault with the product, they stop and do root cause analysis before allowing the machines to run. The quality gets built in by the time the product is rolled out.

5. There are 8 different kinds of wastes that can happen in a system

• Overproduction
• Waiting
• Unnecessary Transportation
• Over-processing
• Excess Inventory
• Unnecessary Movement
• Defects
• Unused employee creativity

6. Toyota CFO expects the entire financial year report on an A3 size format, so that only needed information has been added rather than waste

7. There are two kinds of Kaizen, Point and Flow

8. There are two sets of people, the bike thinker and the frog thinker. Basically, a bike can be disassembled easily, individual components can be optimized and put back. However a frog, once disassembled cannot be optimized in isolation without affecting the other parts. Software development needs Frog thinking.

Tips for effective offshore software development

A decade of experience while working with distributed development environment has taught me some lessons and techniques to effectively work in this mode. In the following paragraphs, I have shared my observations and also, way to tackle common issues in distributed environment.

Image Source: http://www.benscheele.com/ray_imgs/abstract/abstract1.jpg

It is very important for onsite teams(read it as non-Indian outsourcing partner) to understand the culture of offshore teams (read it mostly as Indian teams). Specifically the cultures are extremely different in countries like India, china, Brazil, Manila as compared to the cultures in US, UK, or any other European countries.

Many a times the business people from onsite companies visit offshore, finalize the software vendor, sign the contract and return back. By this time, they would have already signalled setting up onsite and offshore software development teams. The onsite/offshore development teams start working on the software project even before they can properly spell each others names .

I have also observed the following differences in the way of working between onsite and offshore teams

Saying "No" : Offshore teams don't say "no" easily. They won't come up with issues easily as they don't want to hurt the other person. This is more of a cultural issues I think. I have come across many instances where offshore developers were fine getting the blame for not doing something even though the onsite teams have not provided them the sufficient information to proceed. Many a times in small and medium sized firms vendors give more than necessary due importance to the customers to keep them happy and are never blamed. This in turn adds significant fuel to fire in ensuring that the offshore developers keep quiet and nod their heads.

It is necessary for offshore teams to stand up and say "no" when necessary and at the same time , the onsite team leads should keep a tab on "bullying" developers.

Networking & Socializing : Many offshore developers when they come to work tend to socialize and would like to get the work done more informally rather than through formal means. Interestingly western culture is different. Since I used to live abroad, I have observed that the western developers don't want to be disturbed and clearly separate the personal from professional lives. They are very strict about the timings and whom they speak with during work. One of my relatives have been living and working for a fortune company since last 10 years in silicon valley. He says he has never spoken to the coworker who sits next to his cubicle, as the other person too does the same. Both of them come to work at 8 in the morning, eat meals while working, drink coffee while working and go home early in the evening. However in countries like India, having lunch together, cafe together is socially acceptable way of living .

I have observed that many onsite teams who are new to Indian culture don't consider this socializing aspect as cool and they get furious about "wasting productive hours".

It is extremely important to exchange key team members of both the teams for a few weeks so that they understand each others team. Knowing each others name is not sufficient.

Technology and Communication: Somehow western programmers come with inherent ability to communicate effectively as compared to the offshore programmers. So, offshore vendors always spend extra effort to correct this weakness by pushing the senior and more experienced programmers to the front line to manage projects. So, it is difficult to find "programmers" with 10-15 years of experience in offshore teams, however you can easily find "managers". So, don't expect people at 10+ years sit and code as compared to the onsite counterparts. The subject of whether experienced offshore developers should code or not itself is a debatable subject, but let me keep it for another day :-)

Completed 2 Speaking Events

Recently completed 2 speaking events, one in Bangalore and the other in Hyderabad.

The event was sponsored by ITGrids in alliance with Agile Alliance and was attended by nearly 50 people from various software companies in Bangalore and Hyderabad.

Agile adoption in offshore companies

I have been observing an Agile adoption trend/pattern in offshore companies (read it as India). The offshore companies are mostly into softservices with a small chunk into product development.

Offshore Software Services companies seem to be adopting Agile methods mainly due to the request/push coming from onshore customers. Many of these services companies still have projects running applying waterfall model too. My experiences while working with many of these services companies has made me to realize that, they want to retain both Waterfall/CMMI, ISO kind of certifications along with Agile. These companies are neither oriented towards Agile nor Waterfall/CMMI, and they are only customer and Profit centric.

P.S: In the above paragraph, I have used Waterfall and CMMI together. Even though I am not an expert on CMMI but I have observed that the CMMI recommendations are mostly applied with waterfall process by many companies.

Typically this is what happens when a new customer walks into one of the offshore services company. The offshore company show them the menu with various process options. Based on customers choice, the process would be customized and applied on that particular project.

Above observation is leading me to come up with some new questions and I have also attempted answering them...

Questions include

1. Can CMMI and Agile coexist ?
2. Can Agile methods sustain in such environments ?

Answering Q. 1 above, I do believe that CMMI and Agile can coexist. I have observed many companies bringing these two giants together.

Answering Question 2 above needs bit more explanation. I feel that, Agile methods cannot sustain in such environments. Reason being, the CMMI concepts coupled with Waterfall model needs a mindset which is totally opposite to the one needed by Agilists.

Some of the conflicting practices/mindsets include

1. Self organizing/Self Managing teams in Agile as opposed to "one man show" in Waterfall
2. Iterative Vs BigBang approach
3. Daily estimation Vs One time estimation
4. Customer collaboration Vs "Fire and Forget" customers policy
5. Regular Iteration Retrospectives Vs Postmortem sessions after the project

If the CMMI/Waterfall company wants to set up an Agile practice group, it is recommend to create two different groups to manage these two different processes rather than allowing only one person to manage both of them. I have interacted with many Quality/CEPG/CMMI Auditors, and they are so obsessed with waterfall concepts that they don't believe in Agile. If the stakeholders of the companies make such people as the sole group heads to run both Agile and CMMI processes, then it is pretty clear that, Agile would get slow death.

Another draw back I have observed in "Client driven Agile" projects include, that the offshore companies will never be able to appreciate the real value of Agile. Since Clients would be driving the Agile practices, the offshore teams just follow them blindly without knowing the Whys behind them. This leads to misconception and creation of Agile myths.
Successful implementation of Agile methods in offshore projects depends on couple of key points.

1. It needs a good support from both onsite and offshore team
2. The onshore team also has to ensure that the offshore team and the stakeholders running the company are well aware of Agile in addition to understanding the values and benefits of Agile methods.

Even though Agile is picking very fast in offshore projects, benefits of the offshore companies taking lead in propagating Agile is more than the onshore teams driving it !

Impact of "Individual Performance rating" on projects

Many thought leaders have recommended organizations to follow "team performance ratings" rather than "Individual performance" ratings. Many books and blogs have been written about the topic. Even though I have read the cons of individual performance ratings in the past, recent story that I heard from a friend reinforced my belief about the negative impact of "individual performance ratings" on morale of the employees.





Here is the story, John (Say, not real name), is working for a mid sized company and the company is following waterfall model of software development. John is working on a project which has tremendous pressure and tight deadlines. His project has fixed schedule and fixed budget(cannot add more people to the project too), no room for any flexibility in the project plan. The release date of the project is carved on the stone already. Just imagine what would be the fate of the developers working on this project !!

So, John went ahead and escalated this issue to his superior about the team loosing morale, loosing patience and getting stressed out on this project. Superior refused to provide any support because this project is a high profile project and if the superior tries to bail the team out or try to do anything which affects the project deadline, the Superior's "promotion" which is due this year would get affected !!

After listening to the above story, I felt that, as long as an organization has "individual performance ratings" in place, people tend to keep their individual priorities/preferences above "the team's" or "organization's" goal. In order to get good rating, Every one in the team works hard to achieve their personal goals and in the process forgetting the organization/team goals.

Taking the above story a bit further, what might happen to the project now ? May be the team would put all efforts to meet the deadline, might even don't express their concerns around stress with any one (avoiding getting beaten up during the performance appraisal). However this stress is definitely going to affect the quality of the code that the team is developing. isn't it ?

Do you have any such stories ? feel free to share them here.

Identifying a Scrum Master for a new Scrum Project

Recently my article on "Identifying a Scrum Master for a new Scrum Project" got published on Project Perfect. I have pasted the article below with a bit modification.

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 “The person should be 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 gained experience by 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 any team members from the existing waterfall team to be a Scrum Master? It is a tough decision, isn't ? . What criteria would you to pick that special person for the team ?

Even though there is no rule that only "senior" person should be picked as Scrum Master, I have observed in most of the projects that the senior most person in the team typically possess “most” of the above skills as compared to the rest in the team, and that senior most person typically is 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.