I have posted the following article on my new blog Agile offshore blog
There are number of ways how a team can conduct Scrum meeting in an offshore environment.
It is always recommended to have the answers for the 3 questions ready before attending the Scrum meeting. In an offshore environment, the Product owner sitting onsite(Ex:Australia) may not be able to attend the offshore scrum meeting (Ex: India at 10 Am in the morning) due to time differences. Sometimes, even though PO is able to attend the scrum meeting, he/she might have issues w.r.t language and accent (Ex: between French and English speakers). Such situations have taught us that, usage of tools like a scrum logger would benefit both the onsite and offshore teams.
The offshore team can make use of some tool to input the answers for the 3 questions on a day to day basis before getting into Scrum meeting. The onshore customer (who is having issue with accent or language barrier) can go through the answers daily and can get to know the impediments or any other issues without being a part of Scrum meeting.
The above scenario has been given keeping in mind that only the offshore team is part of development and the product owner is sitting onsite.
Tuesday, April 17, 2007
Thursday, April 12, 2007
Servant Leadership and Chanakya
The servant leadership, a type of leadership development coined by Robert GreenLeaf is one which is referred the most in Scrum community. The Scrum Master is supposed to be a servant leader. Recently, while I was going through Wikipedia, I came to know that, servant leadreship is not a new concept and this concept existed even as early as 4th century. Chanakya or Kautilya, strategic thinker in India has advocated this concept in his books. As per Chankaya
the king[leader] shall consider as good, not what pleases himself but what pleases his subjects [followers]". He argued that "the king [leader] is a paid servant and enjoys the resources of the state together with the people"
Tuesday, April 10, 2007
Agile, Wiki and Trust
Is there any relation between Wiki and Trust ? I know it is difficult to believe, and it is true that there is !! Many organizations and teams use Wiki just as knowledge management tool Or a collaboration tool to share information across different teams spread across geographical regions. But this tool is much powerful than just a knowledge sharing tool.
The information that is shared in this tool shows the trust, the PMs have with their development team, the trust, the customers have with the software services vendor, and the top management has with their employees.
Consider that, you are an employee of a company in sales/marketing division. Can you put the day to day activities of the prospective customers you met that day, the discussions what you are having with the various customers, status of various accounts, etc in Wiki. Why not ??
If you are not doing this, it is mainly because you want to protect your customer information from getting into your neighbor who is another sales/marketing guy. You might be worried that somebody might steal all this information. You might be worried that your information would expose some of your weaknesses in handling the customers.
Consider that you are a developer in a software services firm, and can you put all the problems(as in roadblocks, to achieve goals) you are facing in your project on official wiki ? Why not ?
If you are not doing this, it is mainly because you are worried about exposing the problems of the project to public, customers and to the management and, the finally the consequences of getting thrown out of the project.
In each of the above cases, one of the main problems is the lack of trust within the team and across teams.
As we are aware, Agile methods would succeed only in an environment where people work together with no fear or favor and with trust. Now, coming back to wiki, the amount and type of information you put on wiki without fear or favor decides how much trust is present in your team and as a whole in the organization.
I have seen many organizations having a wiki with access control. It is not bad, especially in a software services firm, while working with multiple customers, NDA would force the organization to mask information from each other. But restricting access to public domain information shows the lack of trust.
If you have read Maverick , you would understand that Ricardo Semler even goes ahead and exposes the company financial information to all employees. Initially the senior management gets worked up and starts worrying about the possible leak of financial data to competitors by employees. During that time, Ricardo asks something like,
The information that is shared in this tool shows the trust, the PMs have with their development team, the trust, the customers have with the software services vendor, and the top management has with their employees.
Consider that, you are an employee of a company in sales/marketing division. Can you put the day to day activities of the prospective customers you met that day, the discussions what you are having with the various customers, status of various accounts, etc in Wiki. Why not ??
If you are not doing this, it is mainly because you want to protect your customer information from getting into your neighbor who is another sales/marketing guy. You might be worried that somebody might steal all this information. You might be worried that your information would expose some of your weaknesses in handling the customers.
Consider that you are a developer in a software services firm, and can you put all the problems(as in roadblocks, to achieve goals) you are facing in your project on official wiki ? Why not ?
If you are not doing this, it is mainly because you are worried about exposing the problems of the project to public, customers and to the management and, the finally the consequences of getting thrown out of the project.
In each of the above cases, one of the main problems is the lack of trust within the team and across teams.
As we are aware, Agile methods would succeed only in an environment where people work together with no fear or favor and with trust. Now, coming back to wiki, the amount and type of information you put on wiki without fear or favor decides how much trust is present in your team and as a whole in the organization.
I have seen many organizations having a wiki with access control. It is not bad, especially in a software services firm, while working with multiple customers, NDA would force the organization to mask information from each other. But restricting access to public domain information shows the lack of trust.
If you have read Maverick , you would understand that Ricardo Semler even goes ahead and exposes the company financial information to all employees. Initially the senior management gets worked up and starts worrying about the possible leak of financial data to competitors by employees. During that time, Ricardo asks something like,
if you don't trust your own employees, why did you hire them at the first place ?
Friday, April 06, 2007
Applying Agile/Scrum practices in Maintenance projects
In many Agile training programs and conferences, common question that gets raised is, does Agile/Scrum works in maintenance projects ?
I always say "YES" and the team needs to tweak Or invent the practices to suit their needs.
Maintenance projects could be enhancement projects OR pure defect fixing projects.
Enhancement projects involve new set of development over existing one. Since the developers gets new set of requirements at the end of each iteration, one can apply the standard set of Scrum practices with little or no modification.
Defect Fixing projects involve fixing defects on closed or current projects not in development. Sometimes these projects are boring, especially if a new team has been hired for defect fixing purposes only. The customer sends a set of defects on a daily basis or weekly basis with a deadline to deliver. The development team needs to fix them ASAP and send the patch for further testing.
While coaching one of such a defect fixing projects, I found that the following Scrum practices can be applied without much modification
1. Daily Scrum meetings
2. Scrum of Scrum
3. Modeling days while solving complex defects
4. Information radiators displaying InProgress, completed, reopened, closed defects and other information
5. Usage of Wiki for collaborating with the customer
6. Requirement workshop while understanding complex defects
7. Review and Retrospective
Common problem that I have found in defect fixing projects include, setting the iteration length. Especially, if the defects are given on a day to day basis without prior knowledge of what you are going to get, it makes the life of the development team bit difficult.
This can be solved by collaborating with the customer and coming up with a plan to have 1 or 2 weeks of iteration length.
I always say "YES" and the team needs to tweak Or invent the practices to suit their needs.
Maintenance projects could be enhancement projects OR pure defect fixing projects.
Enhancement projects involve new set of development over existing one. Since the developers gets new set of requirements at the end of each iteration, one can apply the standard set of Scrum practices with little or no modification.
Defect Fixing projects involve fixing defects on closed or current projects not in development. Sometimes these projects are boring, especially if a new team has been hired for defect fixing purposes only. The customer sends a set of defects on a daily basis or weekly basis with a deadline to deliver. The development team needs to fix them ASAP and send the patch for further testing.
While coaching one of such a defect fixing projects, I found that the following Scrum practices can be applied without much modification
1. Daily Scrum meetings
2. Scrum of Scrum
3. Modeling days while solving complex defects
4. Information radiators displaying InProgress, completed, reopened, closed defects and other information
5. Usage of Wiki for collaborating with the customer
6. Requirement workshop while understanding complex defects
7. Review and Retrospective
Common problem that I have found in defect fixing projects include, setting the iteration length. Especially, if the defects are given on a day to day basis without prior knowledge of what you are going to get, it makes the life of the development team bit difficult.
This can be solved by collaborating with the customer and coming up with a plan to have 1 or 2 weeks of iteration length.
Subscribe to:
Posts (Atom)