Best time to do performance testing in an Agile environment

In the traditional model of software development major release/milestone dates are fixed, and performance testing is done just before such milestones, and it occurs mostly after the completion of coding, integration and system testing for a chunk of requirements. In an Agile environment too, release and milestones dates are planned, however, between the start date and the major release date, multiple iterations keeps happening and developers keep churning the code.

So, the next logical question to ask is,

In an Agile environment, is it still advisable to do
performance/scalability kind of testing before the major release date Or is there a better way to handle this ?

My personal view is, the non-functional requirements(the -ilities, scalability, availability, performance, etc) cannot be separated from the implementation of functional requirements. It is not a good idea to say that we would implement the functional requirements first and then look at non-functional requirements. According to me, one cannot write a piece of code implementing functional requirement without affecting the non-functional requirements. Even the simplest If-Else statements, for() loops we write affect the -ilities in a big way. It is always advisable to have the non-functional requirement related SLAs in mind all the time
and, after writing each piece of code, ask yourself does this line of code
meet the SLAs ?

Moral of the story is, in an Agile environment, performance, scalability, Availability testing is done all the time right from Iteration 1.

Best Practice: It is better to write unit tests to check the conformance of your code against the SLAs, and automate them. Creation of such unit tests and, automating them is the key to success in implementing non-functional requirements in an Agile environment.

Bahá'í Consultation model and decision making

We are making decisions all the time, either by ourselves or by collaborating with others. There are times where it is easier to make decisions and sometimes tough. One of the classic example is performance moderation session that all supervisors and their teams have to go through in their career, one time or the other. Have you ever attended such meetings in larger organizations ?, if not, here is a preview.
Each supervisor/manager brings the data about their team members and each of these supervisors would have come to the meeting with their own agenda i.e. to get promotions/good hikes to their team members. Most of the time, there are more candidates than the allocated budget and this is a tough situation as only a few, can be chosen for hike/promotions. In situations like this where each one is pursuing their own goal and not a common one, decision making becomes even more difficult.

Above example is an extreme one which may not happen daily, however we commonly come across group meetings where collective decision has to be taken.

How do you make decisions in such situations ?
In such situations one of the best suited techniques would be to apply the Baha'is consultation model". As you might be aware, Baha's is a religion. The goal of consultation the Bahá'í way is to discover the best course of action to take for the well-being of all.

Here are the 4 steps in Bahá'ís consultation technique:

1. Establish the full facts;
2. Decide on the principles to be applied;
3. Discuss the matter;
4. Make a decision.

In this technique, each participant would be given an opportunity to express their opinions, and everybody has to vote for all the ideas shared by the participants. This in turn results in ideas becoming "group's" property rather than individual's. People who would have come with malafide intentions cannot push their ideas as the rest of the crowd has to be in agreement. Respect for people and ideas are given highest priority in Baha'is consultation model.

Here are some good resources throwing more light on this model

http://www.planetbahai.org/cgi-bin/articles.pl?article=167

http://www.infonet.st-johns.nf.ca/bahai/consult.html

http://www.bcca.org/services/lists/noble-creation/bic-5.html

This technique could be applied during Estimation and retrospective sessions in Scrum.

Self Organizing team and its limit

There is a limit to everything and including the limit, a self organizing team can reach.

Self Organizing teams are characterized by the following features

• The team members share a common goal
• They collaborate to accomplish their goals
• Each team member shares the responsibility while managing the tasks
• They make their own decisions to achieve the necessary goal
  
• They take responsibility of both success and failure

Copyright

Self organizing teams are considered to be powerful and productive as compared to teams managed by a manager. However the question arises, can the team make decisions which could possible go against the company's goals ? if so, is it all right for self organizing teams to make such decisions ?

For example, a company might want the team to attend the CEO's biweekly presentation, however the team does not want to do so. Can such decisions be allowed ?

Even though self organizing teams can make their own decision to achieve the goal, the team cannot do whatever they want to do. There are certain limitations and framework within which they have to operate.

For example, the decisions made by self organizing teams should

• be in line with organizational goals
• Customers goals
• Goals of the project
  
• be Socially acceptable
  

If the team does not want to follow one or more of the above framework parameters, the stakeholders of the projects have all the rights to take necessary action. It is also important for the stakeholders to understand the root cause of the problem by applying Five Whys or any other techniques.

When would you not apply Agile methods ?

I have been applying Agile methods from so many years and been interacting with many Agile experts. So far I have not seen/heard stories about the projects where it had been felt that Agile cannot be applied. Agile methods should be looked more like a risk mitigation strategy on software projects rather than a "software development process". Agile promotes continuous improvement through learn and adapt cycles.


Following are the possible characteristics of a project where Agile need not be applied:

• The project carries no risks
  
• The stakeholders are not interested in continuous improvement of project quality.
• The stakeholders are confident that the project would go as per the project plan without any deviation. Even if it deviates, stakeholders/teams are fine with it.

Here is Ken Schwaber's take on "not" applying Scrum on projects:

I wouldn’t use Scrum if I were embarking on work in which there was absolutely no possibility of change or the unexpected. I would then confidently plan the project and await the predicted results on the day when it was due for the cost that was estimated. Wouldn’t this be a wonderful world ?

Stakeholders and management team keep coming across situations to make decisions around complex and debatable subjects, similar to the one we are discussing now(Agile - Not Agile). In such situations Ralph Stacey's Agreement & Certainty Matrix might come handy.

Towards an evolutionary design by Venkat Subramaniam

Recently I attended Venkat's seminar on "Towards evolutionary design". Thanks to ASCI and Binary Essentials for sponsoring this event. The event was a huge success and a lot of people attended the event inspite of heavy rains.

Image copyright

Venkat, is a proven software architect and an Agile expert. One can easily feel the passion when he speaks about the evolutionary design and architecture. Here is the summary of key points that I learnt from the seminar

1. Design can be of two types, strategic (high level design, modeling, etc) and tactical design (TDD, Refactoring, etc)

2. He recommended the audience to read the two good articles, "Who needs an architect" and "Is design dead ?" both by Martin Fowler. Another good book he recommended us to read was the Humane Interface by Jef Raskin

4. He explained Kent Beck's Triangulation concept very well. He mentioned that frameworks should be selected based on the need rather than emotions, and he wanted the development team to avoid "Resume Driven Development(RDD)" :-)

5. He encouraged the architect to apply the "Tracer bullet" concepts while architecting solutions. That is, create a prototype first and use this as the tracer to create a robust architecture.

There were many more take aways from this seminar and I would let his presentation speak about the rest.

The Agile Zone - Papers

I found this web site  The Agile Zone - Papers  with interesting papers, articles and presentations on (or related to) Agile Software Development.   The site lists the articles/white papers alphabetically. 

Technorati Tags: Agile resources,presentations,articles

Summary of Slack

I have been reading slack and also making notes of key points from the book. I always wanted to share the summary of the book on this blog, and incidentally I found that somebody has already done this. Thought would the share the summary here without reinventing the wheel.

You can also read the following summary here written by the author

* In our constant quest to make our organizations more efficient (reduction of overhead, standardization of processes, overworking management and resources), we have actually made them less effective. The solution lies in (re)introducing `slack'. Slack is the lubricant required to effect change, it is the degree of freedom that enables reinvention and true effectiveness.
* Multitasking and overtime, thought to be ways of getting the most out of the teams, are actually having a negative impact on productivity. Multitasking, specifically for knowledge workers, causes at least a 15% penalty in productivity. It is much higher for tasks (such as troubleshooting or design for instance) that require complete immersion before the resource can actually make progress. Systematic overtime is also proven to be an ineffective way of improving project cycle-time. While it may provide short term gains, the demands it puts on resources quickly reduces their productivity and effectiveness. An alternative to systematic overtime are well calculated and well timed sprints (focused and value-added, yet handled as exceptions).
* Overworked managers also have a very negative impact on organizational effectiveness. It is indeed managers, and more specifically middle managers, that can the most effectively champion and effect change in organizations. The more overworked they are, the less time they have to reinvent the ways of working. Those same middle managers will be most effective in bringing about positive changes if they can collaborate with each other, which in turns requires that organizations stop fostering destructive internal competition.
* Prescriptive processes, pushed top-down, are a form of disempowerment. They are a result of fearful management that is allergic to failure. These processes succeed in dictate every aspect of how you should do you work but fail in providing guidance in doing the `hard parts'. They are often heavy and form an armor that reduces the mobility and agility of teams, hence resulting in less competitive organizations. The solution is to put the ownership of processes between the hands of those who do the work.
* An effective change manager is a person that can remonstrate, repeat, correct, encourage, cajole, motivate, and has great powers of persuasion. He/she is less of a boss and more of a negotiator. Great change managers have a lot of markers to call in. Markers come from favors done and confidence earned in the past. They have built a reservoir of trust and tap into it to entice their people to embrace change. Change managers have to come from within the organization, a stranger has no markers to call in, just a little `honeymoon capital'.
* The best time to introduce change is in a period of growth. Decline causes anxiety and makes people more resistant to change.

Human angle in Software development

No matter what methods(Agile, traditional, Evo, FDD, RUP, etc) that is applied for software development, the only thing that decides the fate of the project is people.

There are many traditional projects that have been delivered successfully, and Agile projects that have failed miserably. The success or failure of projects doesn't depend on the process or framework that is being used.
According to me, it all depends on the people who are planning ,executing and maintaining the project. When I say people, it need not be the poor software developers, it could be PMs, customers themselves, marketing/sales people, finance team, etc.

The project's fate gets decided right from the time the marketing/sales person starts selling the skills/services to the prospective customer. I have seen many instances where the marketing/sales team over commit with the customers for the sake of winning the project. Ultimately when the actual work reaches the architects/project managers/developers, there will be little room left to make any changes. In most of the projects, the timeline is fixed, the only thing that is allowed to be flexible would be resources(a few lucky ones).

Even after so much of campaign happening around software process improvement, the project stakeholders add/remove people to the projects based on simple arithmetic. They don't look at software developers as humans but instead like chairs/tables/"things" that can be replaced and used right from the time it is purchased.

Here is an example and explanation of the above paragraph:

Let us say it takes 400 person days worth of effort to implement a feature . Naturally the stakeholders will calculate and say that if 20 people work on this feature for the next 20 days this work could be completed.

There is no flaw in the above calculation. However, the stakeholders never even think of buffers due to attrition or addition. What I am trying to say is, let us say the above team of 20 people start working on the project and they have completed 10 days (i.e. 20 P * 10 D = 300 PD complete). Let us say, the 11th day a team member quits the project. Consider the best case scenario where they found a new replacement person the same day.

My question is,

Even after finding the replacement the same day, what are the chances of completing the project as scheduled within the remaining next 10 days ?

According to me, the delay would be more than 5 days. Reason being, when a new person is introduced into any project, it not only takes some effort to psychologically adjust to new team but also takes effort in understanding the work. Unfortunately, in most of the cases I have seen the stakeholders don't consider the human angle and still push people to complete the work as planned because the new replacement was found the same day !!. This push in turn leads to reduced thinking due to time line pressure and ultimately reducing the quality of the work.

In Slack, Tom Demarco puts this process of replacement as "personnel turnover". As per research, the effort and the cost associated with personnel turnover could be as big as 25% of overall project effort. The cost may not be visible directly but it gets incurred due to delivery delay, training new personnel and defects fixing.

Until human angle is not given at most importance in any project, the project will go through turmoil no matter what method they follow !!

State of Indiana Makes Using Waterfall SDLC’s a Criminal Offense

Recently I came across this article which claims state of Indiana passing a bill against use of Waterfall SDLC.

Read the first para of the article here ....

Waterfall software development lifecycles have terrorized technology projects in this state for too long,” Governor Mitch Daniels said at a simple signing ceremony held at a meeting of the Central Indiana chapter of the Project Management Institute (PMI). “This bill will end the tyranny of big upfront planning, big upfront design, and litigation style change management.”
The bill, which goes into effect immediately, will make it a criminal offense to use software development lifecycles
that divide software projects into serially executed phases
distinguished by a particular type of work activity. Violators will be
stripped of their project management certifications and could face up to six weeks in jail for their first offense.

Read the complete article here.

The article has been written with such a perfection that people would take some time to realize that this is a joke :-)

Agile/Scrum podcasts

Check out the podcasts on

• Scaling Scrum
• Agile Estimation and Planning
• Essential Scrum
• Next step in Unit testing

Above sessions feature Agile experts like Rachel Davies, Roman Pichler and PushtoTest CEO Frank Cohen

Agile Myths

Many newbies to Agile bring tons of myths and misconceptions. They would have picked this baggage either by attending a seminar, reading a book or blog. It is not that the sources are wrong, but these enthusiasts would have misunderstood/misinterpreted the concepts.

Some of the common myths I keep hearing around Agile are :

1. Agile means two people working together on a computer.

Agile is a set of values and principles. Two people working together on a computer is one of the practices from Extreme Programming (A.K.A XP). Many people get confused between the Agile and the implementers of Agile (XP, Scrum, etc).

2. Developers working on Agile projects don't do any documentation

Agile Manfiesto never said don't do documentation. In fact, Agilists say that do documentation only as required that adds value to the customer and don't do it for the sake of satisfying some process.

Sometimes it becomes necessary to maintain extensive documentation, and if so, irrespective of whether it is Agile or not, it needs to be done.

For ex: projects involving avionics or military related projects need extensive documentation, this is keeping the sensitive of the domain in mind. In such cases, one has to maintain documentation because it adds value to the customer.

3. Agile methods cannot be applied for distributed development projects

There are many projects that have been carried out in distributed development applying Scrum and XP. The projects are pretty successful. Key thing to be successful while implementing Agile methods is being innovative with practices. Creativity and Innovation are the key ingredients to succeed in an Agile environment.

4. Agile methods expect the team members to be matured

Another big myth. There is no measurement to classify matured from immatured people. Its all perception and context dependent. Agile manifesto never talks about maturity of people, however Agile suggests hiring good people and trusting them to do the job.

Personally I worked with junior/senior members in various projects. Some team members were very good in communication while lacking in many facets of soft skills. However I found that many Agile practices(like scrum meeting, modeling days, retrospective,etc) helped the developers to improve their soft skills. This improvement is just a byproduct of practicing Agile methods.

5. Agile is not suitable for product development

Agile is being successfully practiced both in services and product development environment. In fact, I feel this is more appropriate for a product development environment. This is because, Agile concepts makes the product development more flexible and more open for changes to sustain in the competitive market.

6. Agile is not suitable for fixed bid projects
Many Agile companies specifically with my experiences in Indian context have been practicing Agile methods with fixed bid projects. If customer is willing to collaborate with the development team and, the development team is transparent with their deliverables then, all these types of contracts/negotiations would take back seat.

I have seen Agile software companies signing fixed bid contracts with the customers. Since the software services vendors are transparent in what they do, any new change request given by the customer is suitably discussed on the table and a solution emerges. The new change request is accommodated either by extending the release date/expansion of budget OR by dropping low priority features.

Here are some more resources on Agile Myths

Agile Mania

Agile Myth busters

5 Agile myths

Building an Agile team

Recently I got an opportunity to build yet another Agile team and wanted to share some of my experiences around it. Here is some initial context before I begin sharing:

• This team has around 5 people , with 2 junior members(<3>
• My company has a strong CMM background and at the same time, provides free hand to tweak the methodology or experiment with new techniques.
• The customer is not worried about whether it is CMM/Agile.
• It is a distributed team spread at many places in India.
• The client sits in US
• Project is research oriented than a development project

When I started recruiting team members and started the project work, I didn't tell the team members anything about Agile or any jargon from Agile methods. I started with the simple technique of having daily meetings (AKA stand up meeting in Agile methods). Here is what we do during daily meeting, every day at the same time we have a call in the morning and a call in the evening. Team members who are in different locations dial in during the meeting. Each person would share their plan for the day before taking the coffee break. All this information collected during the call gets updated on to the Wiki pages.

In the evenings, we discuss what we have achieved since morning and reason for not achieving something. We don't use this information to crucify somebody, but we have built this tradition to help the person in need. People are eager to share the issues and ask for help immediately.

I know that, this type of stand up meeting is a bit different from the traditional ones followed in Scrum or XP, answering 3 questions. I have realized that, many a times the Scrum meeting becomes monotonous and people answer those 3 questions for the sake of answering. In fact, in one of my friend's company, the client has been adamant about having a daily Scrum meeting by answering the 3 questions "at any cost". Many a times, the team members used to cook up answers for the Scrum meeting as they didn't have many things to answer during the call. I have realized over the last few years that the practices should not be enforced on the team members. It should be slowly sold to the team and the value should be exposed to the team members through various techniques. In my case study, the team missed couple of calls however suddenly they realized that they are losing the focus on work and things started looking chaotic. They made even a firm decision not to miss daily meetings.

Usage of white boards

Once the work starts in the day, we don't have any formal meetings but many of them are through informal discussions. If somebody has a point to share or want to discuss they will go to the white board and write it. We have a regular customer call and we read the points written noted on the white board to discuss any roadblocks with the customer. Because of this, we don't forget many things.

Usage of Spreadsheet

We use spreadsheet as the project tracking tool. On a daily basis we just update the status of each task. As and when we come across any new task, it gets inserted into the spreadsheet. It is amazing to know, how many "unplanned" tasks gets added into the project planner. This tool was created iteratively. As and when we found the information to be useful, we used to either create a new column or add a new status or anything else.

Use of Wiki

All documents are directly typed on to Wiki, no documents gets circulated via email.

Client meetings

Every team member whether junior or senior attends the regular customer call. In turn this has resulted in more efficient spread of knowledge and efficiency at work. Most of time, in many projects run in India, I have seen only the project managers/architects participating in calls with the customer. This results in team members not understanding the reality and never getting to know the first hand information. There are pros and cons to this practice(at least in the Indian context), but I feel there are more pros than cons.

Our team is still young and I am in the initial stages of buidling this Agile team. I still have a long way to go before I introduce retrospectives and other good practices ......

Self organization and Swarm Intelligence

Recently I read this article about Swarm Intelligence. This article talks about amazing efficiency of the insects like ants, wasps, bees, etc. The scientists have researched the behavior of these insects and, have proposed ideas that could be used in our day to day business. The portion of the article that caught my attention was the 3 characteristics of social insects that is making them successful.

They are

• Flexibility
• Robustness
• Self organization
  

Flexibility and robustness is influenced by self organization. The articles claims that

Through self organization, the behavior of the group emerges from collective interactions of all individuals

In the case study given in the article, the ants, bees don't have a leader directing day to day activities. The social insects seem to have two key priorities in their life time, finding food and defending against enemies. It seems to be a simple life as compared to human beings :-)
There is no need to have a backlog of tasks to monitor of the ants/bees. They get up in the morning, go in search of food, bring it back to their nests and live happily.

I was wondering why can't we be self organized like them(atleast in our work life) ? Specifically, Agile methods recommend self organizing teams. My take on this is, we as human beings can't be like ants, bees. It is very difficult (even though not impossible) for human beings to self organize themselves at work. We have many needs, desires, characters, emotions. Each of these parameters affect our thought process and decision making ability. We have our own individual identities as opposed to the ants and bees. May be these social insects have their individual identity, but looks like they give higher priority to the group rather than their individual wants/desires. I think we can achieve self organizing teams within our projects, provided we keep aside our individual priorities and work only towards the projects goal.

couple of questions that is coming to my mind..(for readers)

1. Is your project leader capable enough to create a strong goal that would make you to lower your personal priorities ?
   
2. Have you seen any projects with self organizing teams ?
   
3. What does it take to become self organized in your project ?
4. Are you willing to lose your identity for the project's goal ?
   

So bottom line is, it is easier for ants, bees and other social insects to self organize as compared to us, human beings.

Scrum Meetings Vs Scrum Events

Some of the common events that is practiced by Scrum teams include

• Daily Scrum meeting
• Scrum of Scrum meeting
  
• Requirement workshop
• Modeling days
• Review sessions
• Retrospective sessions
  

Scrum teams would be conducting one or the other meetings mentioned in the above list, every day. New teams practicing Agile methods specifically Scrum would feel that, there are more meetings in Agile as compared to the number of meetings in traditional methods.

I think one of the reasons why teams start resisting these meetings is because, they might be practicing the methods not in true spirits (not understanding the true value of these meetings) but for the sake of "doing" it.

What is the solution for such teams ?

1. Coaching the teams about the values of these meetings. This could be done with the help from an internal/external Agile mentor/coach.

2. Change the vocabulary: The word "meeting" is kind of becoming synonym for "obligation". So, whenever the team hears the word "meeting", they start resisting unconsciously. One of the ways proposed by Tobias Mayer is to change the vocabulary. For ex: rename "meeting" with "discussion","working session", "event", etc.

After reading Tobias's email, I became conscious of impact on our mind; usage of the words like "firefighting","postmortem","warroom". Beleive it or not, each of these words increases stress,blood pressure level when uttered. Next time when you utter these words feel yourself.

Right way to do Agile

If you are practicing Agile methods, I am sure at some point of time, you would have asked yourself or somebody else,

Am I  practicing Agile, the right way ?.

I would like to call this as an "eternal question on Agile".

If you visit any of the Agile related Yahoo or Google groups, people would be asking the same/similar eternal questions.   I conduct many Agile training programs and coach teams, and I keep getting similar questions.

There are many such questions. Some of them include  :

• What is the ideal length of iteration ?
• Do I need to practice Scrum meeting everyday ?
• I am working on maintenance project, do I need to practice Scrum meeting every day ?
• Can we have multiple Scrum Masters in a Scrum team

When I hear these questions, I feel that there is something missing in their understanding of meaning of Agile/Agile methods.

As we know, Agile is all about values and principles. These values and principles are manifested into practices with the help of Agile methods like XP, Scrum, DFDM, etc. But, the practices not limited to the one recommended by above methods. Beauty with Agile methods is, one can invent any practice/set of practices one wants provided the practices don't violate the values and principles.

You would say that's fine, I understood but where are the answers to above questions ?  My answer would be,

• Invent any practice you want provided you satisfy the customer and team
• Modify any practice you want provided it does not violate the Agile values and principles. It should be done after taking the team into consideration and a thorough research.

Practices should not be modified to satisfy an individual's taste. Many of the practices proposed by XP, Scrum are recommended after a thorough research and they have their own benefits. Some of them when practiced, are intended to identify risks and issues in the project. When a team practicing Scrum hits a painful point, they would tend to tweak the practice to reduce the pain. But instead I would recommend the team to retrospect and see the hidden issue behind the pain

 

Technorati Tags: Agile,XP,Scrum,Practice,Invent practice,right way to do Agile

Agile Austin and wealth of resources

Agile Austin maintains a wealth of resources on Agile methods.

If you visit their website and click on the Resources link in the left navigation pane, you will find a great list of Books, websites, listservs, blogs, podcasts and videos to get you going.

Attributes of a true Scrum Master

As per Tao Te Ching

The worst leader is who people despise, a good leader is who people worship. A great leader is he who makes people say "we overselves did it"

If you really look at the responsibilities of a true Scrum Master, he is supposed to be a great leader. One of the key responsibilities of a Scrum Master is to create a Self organizing team, where team is empowered to make decisions, lead the project towards the goal.
* A true Scrum Master(SM) won't spend time micro managing activities of the team and instead, he/she would be working towards creating a space for the team to express themselves.
* SM steps out observing the team, coaching them to move in the right direction. This process of empowerment ultimately makes the team feel possessive about the project and creates an image that "they" did everything.
* A true Scrum Master would stay as an angel not in the view of the team, but keeping a watchful eye on every movement of the team.

So, going back to the quote from Tao Te Ching, the Scrum Masters should not consider themselves as "transformed project managers" but work towards becoming great leaders, satisfying the true meaning of "Scrum Master".

Even though no body is born as a leader, I firmly beleive that some of the leadership skills could be developed by observing other leaders.

Agile world in the Top 20 Blogs

Agile Daily has rated my blog Agile blog in the top 20 list as the most recommended blogs on Agile development.


Here is what they say:
Sorted by Fastest Gain in SocialRank. These blogs had the biggest increase in attention today.

1. Geek Noise
2. ASP.Net
3. James Shore
4. Agile Advice
5. Agile Game Development
6. Jason Yip - Blog
7. George Dinwiddie - Blog
8. Agile .NET CT
9. Agile Programmer
10. Agile Israel
11. Agile Software Process Improvement
12. Me.Andering
13. Diana Larsen - Blog
14. Jeff Sutherland - Blog
15. Agile Artisans
16. Agile Blog
17. TargetProcess
18. Agile Project Planning
19. Better Ways of Developing Software
20. Agile Software Development blogs

Accountability and Productivity

I have been reading one of my favorite books Slack, and in one of the chapters on schedules, Tom brings up a good point about accountability and productivity. He mentions that

When a schedule is not met, those inclined to pass out blame are quick to
point at the lowest-level workers; they reason that performance is the domain
entirely of those who perform the work. They ask plaintively, "why can't these
guys ever meet their schedules" ? the answer that the schedule might have been
wrong in the first place only befuddles them.

He continues to say

There is such a thing as a bad schedule. A bad schedule is one that sets a date that is subsequently missed. .... If the date is missed, the schedule was wrong. ... The purpose of schedule was planning, not goal-setting. Work that is not performed according to a plan invalidates the plan.

My blog feeds are available through ASCI

Agile world blog's posts can be viewed through Agile Software Community of India(ASCI)'s website.

Reducing the stress during software development

We keep seeing the stressed out software development team and the customers, blaming and pointing fingers at each other day in and day out. There are several reasons which causes germination of stress in the team. Some reasons include, poor top leadership, unskilled team, unsupportive customer and poor project planning to name a few.

In this post I am going to share some of my thoughts on reducing the stress by creating a proper project plan and estimation by keeping the forces of nature in mind.

Project plans are always good but it should be flexible enough to accommodate changes, considering the forces of nature in mind. The project dates and numbers should be thoroughly reviewed quite often and should be negotiated with the customer for any changes. The process of having a adjustable project plan is the key to reduce lot of stress for the entire team, including the customer.

Before I discuss about stress, let us review some of the commonly adapted software estimation techniques and their pros and cons.

1. Many projects use unscientific estimation techniques, which are mostly the "gut feeling estimations" and this leads to estimations being way off the right path. The poor estimates are either due to lack of skills to estimate or inability to think through risks and consider the risks during estimation.

2. In order to mitigate the risks due to unscientific estimation technique, shown above, many teams simply add 20% buffer to the total effort before submitting the estimates to the customer.

3. There are some light weight estimation techniques like Wide band delphi, planning poker using fibonacci series, relative estimation techniques, etc. which are found to be more accurate than the gut feeling techniques.

4. As per the cone of uncertainty, actual duration to complete the projects can be 4 times or 1/4th of the initial estimations. So, if one has to ensure a guaranteed delivery of the product to the customer, then the development team should do an optimistic estimate and multiply the number by 4 before committing the delivery date to the customer. Even though this theory is supposed to hold good for product delivery, no customer would agree with this model.

Moral of the story: So far no body has been able to come up with a model/formula which can give an accurate estimate and estimates remains as guesstimates most of the time.

Ok, Why is it not possible to give an accurate product delivery date and time to the customer ?
Because, it is we(human beings) who develop softwares. Until human beings are in control of software development one cannot give accurate numbers.

But Why ?
Because human beings themselves are controlled by forces of nature.
What are these forces of nature ?
Basically these are our surroundings, our friends and family with whom we interact everyday, our own emotions which are controlled again by our surroundings, etc.
Examples include : employees can fall sick forcing them to apply leave without any notice, government can change rules which can directly/indirectly impact personal productivity, natural disasters like earthquake, volcanoes can affect work etc

Ok so how is this related to stress ? Typically project plans are created at the beginning of the project and as described in the sections above, the PMs would add some buffer to the estimate before submitting to the customer. Major problem arises as this project plan and estimates are considered to be carved on stone without leaving any breathing space for natural forces to play. Even the 20% buffer on the optimistic estimate is not sufficient as natural forces cannot be predicted by %s.

The above said "Unnatural forces project plan" would be made as the guiding torch by the PMs to achieve the project goals. These plans are given to the developers to execute, which in turn forces the brave software development soldiers to fight every problem arising due to natural forces. These fights would in turn increases the blood pressure, heart beats of every team member. By the team the team reaches the end of the overshooted project, they would have won the half battle of the product delivery but would have definitely lost their mental peace.

How do we reduce this stress in above situation ?

• First and foremost, acknowledging that there are forces of nature and we as human beings are controlled by these forces, every second. This is not the other way around.
  
• As and when we see the blood pressure raising or the heart beat increasing, be aware that some forces of nature is casting its shadow somewhere. Bring this immediately to the attention of the customer and discuss the impact of this on the entire project. Try to make accommodative changes to the plan.
  
• If the customer does not understand or does not want to cooperate on reestimations, bring this issue to the notice of your superiors. They in turn could influence the customer.
  

Finally managing one's stress depends on choosing whether to cooperate and plan to work with forces of nature OR to drive against it. Finally you might drive against the forces and win, but at what cost ?

"Done" ness and "done grading" system

The concept of "Done" is not new to "Scrum"ilists. Scrum prescribes that a "Done" check list should be created by the team together with the Product owner. But still the Product owner has the final say in choosing if the iteration is "Done" or "not".

Many people argue against using the "Done" checklist, because they consider this to be non-Agile and also consider this checklist to increase the stress on the team !!!

How is it non-Agile ?
Its because, it goes against the Agile values and principles. Agile methods are based on the fact that project work is unpredictable and they suggest empirical control theory of learn and adapt cycles. Now in case of "done" in Scrum, the product owner(PO) goes through the "Done" checklist, and sets an expectation for the team to achieve certain things by the end of the iteration. If the team is able to deliver "all" the things in the checklist an iteration would be termed success or could easily be termed "failed" iteration.

But don't you think "enforcing" "done" on the iteration is like enforcing the people to think that "everything in a project is predictable".

So, can we abolish "done" checklist and give a free hand to the team to do whatever they want to do ? How do we measure if team is really on the right track ? how do we know if the team is doing things which adds value to project ? How do we measure the quality of the iteration ?

Here is what Jeff Patton wants to say about measuring quality of iteration.

Jeff Patton recommends a grading system for features in an iteration. :

1. In a small group, brainstorm the major features of your product.
2. Independently for each feature write your "grade" for the quality of the feature. Answer the following questions: Do you like the feature?; Do you like using it?; and Is it a valuable part of the product? Let your answers help you grade the feature with an A, B, C, or D, or fail it with an F.
3. When done, discuss your grades with those in your group. Agree on a grade that best represents the group's opinion of the quality of that feature.

After looking at the recommendations of "done" and "grading", I have been thinking of proposing a new model providing the best of both worlds. I am going to call this as "done grading" system as this is a mid way between the above two theories.

Here are the steps I propose:
1. At the beginning of each iteration, the team would sit with the PO and create the "done" checklist. This checklist is created to understand POs expectation for the iteration. I feel having "done" checklist sets the right expectation and provides a clear goal for the team to proceed further. Without a clear goal, the team would still be working but without a common goal.

2. At the end of each iteration, the PO would still go through the "done" checklist, but instead of calling it "yes" or "no", he/she grades the iteration based on completion of tasks.

For ex: if the team has following tasks in their "done" list

1. delivering A,B,C features
2. unit tests for all features
3. regression test cases and testing
4. automating the tests
5. Introducing TDD
   

and, If the team has partially achieved the above goals, then the PO can chose grade as "A", "B" or "C", etc based on his satisfaction. Once the grading is done, and during the Iteration review session, PO would sit with the team to do a root cause analysis for poor grading of tasks. This session, provides rich inputs to the team, and this data could be utilized to improve the grading in the upcoming iterations.

By applying the above mentioned "done grading" system, the team is relieved of "stress" at the end of each iteration . This is because the iteration would be measured on a more collaborative way of "done grading" system rather than the earlier binary "done" system.

Agile conference in Oralndo, FL December 3 - 6

Agile Development Practices
December 3-6, 2007 * Orlando, FL
Shingle Creek Resort
http://www.sqe. com/go?adp07ng

Conference Web site: http://www.sqe. com/go?adp07ng
Master Schedule:
http://www.sqe. com/agiledevprac tices/Schedule
Download Brochure: http://www.sqe. com/go?adp07broc h
Keynote Sessions:
http://www.sqe. com/agiledevprac tices/Keynotes
Pre-conference Tutorials:
http://www.sqe. com/agiledevprac tices/Tutorials
Concurrent Sessions:
http://www.sqe. com/agiledevprac tices/Concurrent
Register Now:
http://www.sqe. com/agiledevprac tices/register

************ ********* ********* ********* ********* ********* ********* ****
**

WIN A REGISTRATION
Win a Registration to Agile Development Practices 2007! Request a
brochure or register for the conference by November 9, 2007 and be
entered to win 1 of 10 complimentary full conference registrations!

Click here for full details! --> http://www.sqe. com/go?adp07cont ng

Wanting to go to the conference but not sure if there is money left
in your training budget? Try your luck and enter the drawing for 10
complimentary registrations. Attend Software Quality Engineering' s
first Agile Development Practices conference to hear from some of the
best experts in the business. Choose from over 75 sessions to build
your own information- packed event complete with practices, processes,
technologies, and leadership principles geared for agile software
professionals.

************ ********* ********* ********* ********* ********* ********* ****
**
SPECIAL DISCOUNT
Save up to an additional $100 off your registration fees when you use
promo code NGAE during the registration process. For more
information, call 888-268-8770 or 904-278-0524.
************ ********* ********* ********* ********* ********* ********* ****
**

We're pleased to announce Software Quality Engineering' s first Agile
Development Practices conference coming to Orlando in December.
Whether you're investigating or implementing agile development
practices, processes, technologies, or leadership principles, this
new conference has solutions for you. Brought to you by the producers
of the STAR conference series and the Better Software Conference &
EXPO, you have our guarantee that you will experience the first-rate
quality and commitment that have defined Software Quality
Engineering' s conferences for the last 15 years.

Brochure Now Available
Download the brochure now to build your own conference from over 85
sessions.
http://www.sqe. com/go?adp07broc h

Don't Miss Out on the New Open Spaces Sessions
Want to discuss a topic that is not on the program? Great! You need
Open Spaces. We supply the room and the chairs. You supply the ideas
and the leadership. Choose a topic you'd like to discuss, pick your
timeslot, promote your topic at the conference, enroll others, and
have a ball.

That's what Open Spaces is all about—you are in charge of your
learning.

The basic principle is: Everyone who comes to an Open Space session
must be passionate about the topic and willing to take some
responsibility for creating learning out of that passion.

Five other key principles are:
1. Whoever attends is the right person.
2. Whatever happens is the only thing that could have happened.
3. Whenever it starts is the right time.
4. When it is over, it is over.
5. The Law of Two Feet—If you find yourself in a situation where you
aren't learning or contributing, go somewhere else.

If you've never tried Open Spaces, do it now. You'll teach and you'll
learn.

For registration information, please email sqeinfo@sqe. com or call
our Client Support Group at 904-278-0524 or 888-268-8770. To register
on the Web, visit http://www.sqe. com/agiledevprac tices/register

Agile in Product Company Vs Services company

During many of my Agile presentations, I keep getting the similar question from participants, "Can Agile work in services company" ?. My answer has always been "Agile methods could be implemented whether it is product company or services company".
I kept wondering where this misconception is coming from ? I think I have some clue here. ..

As we know, the software services company would try to cater to the needs of multiple customers. Many of the companies would be working on multiple projects ranging from Java/J2EE to COBOL, AS/400, etc. The verticals would be from retail domain to Avionics. As far as I have seen in Indians services company, each project is controlled by the customer's project team from distant locations. Even though the PM and the developers form the major crowd in the team, they have very little say in major project related decisions like choosing tools, process, etc.
The vendor software company has to negotiate with each of the customers about process, tools, methods, etc. Even the management of vendor companies cannot put their foot down about ideas because, there is a tough competition in the market. There is a fear that, many customers can walk out if they find any resistance to their own ideas. Keeping the above factors in mind, it becomes difficult for services companies to convince each and every customer about Agile method or any similar thing. This also results in poor implementation of methods like Agile in services organization. According to me, Agile methods can work successfully in services company provided there is a good support from not only from the vendor management but also customers .

Where as in product development companies, there is one team at the organizational level making all decisions about software development. If the management team is convinced about Agile, that is enough to take the idea forward with less resistance.

XP Day Manhattan - Oct 13th 2007

Upcoming XP Day conference in North America would be held on Oct 13th. Here is the note shared by Niraj Khanna of Diaspar software about the upcoming XP Day Manhattan program:

Diaspar Software and Thoughtworks is proud to present another
installment of the XP Day North America series: XP Day Manhattan
taking place on October 13, 2007.

The focus of XP Day is to bring top extreme programming practitioners
to North American XP communities to share their successes, failures
and perspectives on how to release high-value software sooner.

Our program for Manhattan includes:
1) A keynote address by Steve Freeman. Steve is a fixture in the
London software development community, a regular organizer of the
original XP Day, well known for his contributions to test-driven
development practice and co-recipient of the 2006 Gordon Pask Award.
2) A tutorial by JB Rainsberger, a recipient of the 2005 Gordon Pask
award. JB will talk about why XP works using the Theory of
Constraints model developed by Goldratt.
3) A tutorial by George Dinwiddie, a respected member of the XP
community, and author of an insightful blog about coaching XP teams:
http://blog. gdinwiddie. com. George will talk about sustainability at
multiple levels in XP.
4) Open Space. There’s plenty of room, the space is superbly run and
the conversation is lively. Collaborate intensively with both local
and invited advanced practitioners on issues that interest you most.

Cost of the conference is $249 US)and includes breakfast and lunch.
Registration is limited to 100 attendees. To register visit http://
www.xpday.info. For group rates, contact me at the address provided
in the header of this message.

Check out the following links for pics of our last conference: http://
tinyurl.com/ 2ysz6v and http://tinyurl. com/23ktwx

11 Ways Agile Adoption Fails -- Jean Tabaka

Jean Tabaka a great writer, Agile coach has written a good article on reasons behind failure of Agile adoption in organizations. Read the complete article here

In fact my previous article published on Agile Journal covers many of the above points and I can say the article compliments it.

Craig in UK conducting Agile Projectmanagement course

Craig larman guru in Agile methods would be conducting the course on Agile project management in UK. UK Readers of this blog can avail this opportunity. More information about this course is available here. Also there are some giveaways for early bird registrations and you can use this quote SKIL-PTC671 to get all those early bird prices.

Rupee Appreciation and Agile/Lean practices

One of the hot topics being discussed in the Indian IT sector is how to beat the rupee appreciation against dollar. Here is an article explaining various moves by Indian software giants to handle the current rupee appreciation issue. Most of the decisions taken by these software giants are the ones usually taken during financial crisis. These decisions include laying off employees, asking employees to work overtime with no extra pay, or increasing the hourly rate for the customer.

My view is, one could effectively utilize the dollar earned during every hour by incorporating Agile and Lean practices. Some simple practices(as explained in many of the Agile and lean books) include,
1. Project managers sitting with their team rather than in a far off cabin. This reduces waste due to frequent walking up and down by the team members to PM's cabin.

2.Having enough supply of coffee, tea or snacks within each project room. Otherwise, a lot of time gets wasted when the team goes to a far off cafeteria. As it is evident that even though the customer is billed for 8 hours per day, effective value generated is only worth 6 hours(Ideal Engineering Hours) . The wasted 2 hours can be effectively utilized in situations like the rupee appreciation issue impacting Indian IT sector.

3. Improving communication and collaboration using tools like Wiki, Skype, etc.

4. Redirecting the investments on expensive tools and looking at simple solutions such as usage of digital cameras, white boards, post-its.

5. Improving quality of code and reducing defects by early and continuous integration.

6. Applying the engineering practices like Test Driven Development & refactoring right from the beginning of the project.

and many more...
bottom line is, one could start fixing the issue internally by adopting the right processes, which adds value to the customer rather than applying the usual "inside the box" solutions.

Money transfer to friends and family made safe,quick and easy.iKobo Money Transfer is a new method of remittance that is easier and more secure than sending money orders

Absolute estimates and Relative estimates

As soon as you ask any software developer about the effort it takes to implement a particular requirement, the answer would be either in hours or days. This is called absolute estimate and in the agile world the concept of relative estimate has been introduced by Mike Cohn(atleast as far as I know !).

In case of relative estimates, one would estimate the size rather than the effort relative to each other and then, this size could be mapped to effort based on the velocity/some other means. But the key thing is to understand the applicability of relative and absolute estimation techniques.

Story points are the units used frequently while applying relative point estimation technique.

Coming to the applicability part, the business people want to know how many days or months it would take to deliver the product. You can't tell them that the requirements takes 55 story points, these numbers may not help them to allocate budget or prepare themselves to market the product. They should always be given the absolute estimates. But, the route to absolute estimates at this point should be through relative estimates. This is because, as we move higher the abstraction the clarity reduces and accuracy with absolute estimates decreases. At higher abstraction levels relative estimates suit better than the absolutes. The maturity of the team lies in converting these relative estimates to absolutes and sharing with stakeholders.

Generally, product planning, release planning phases are at higher abstraction level than the iteration planning phase.

At iteration planning level, one has more understanding of requirements and can be more accurate in providing the absolute estimates.

Trends in Software Development methodology

Here is a good article about the changing trend happening around software development, what business people are thinking about software development methodologies and much more... Check out the following article

Thinking like Scrum Master

Most of the time our behavior/attitude would adjust automatically to suit a particular role or designation. For example, If somebody is a senior developer he would be spending time thinking only about solving a technical problem, he wouldn't worry or think about leading a team most of the time. His thinking gets limited to certain area of his responsiblities only.

Similarly, as one is promoted to become a project manager or Scrum Master, thinking patterns would automatically gets adjusted to lead the team and showing attributes of a leader. Fundamenally people wait for suitable title/designation and then would try to change their thinking patterns, atleast most of the times !!

Recently, Pete Behrens one of the Agile practitioner suggested a good thought in the Agile discussion group, and thought I would share here:

If you wait for a title to behave as that title you will rarely make it
there - rather if your act and behave what you want to become,titles become
some what irrelevant.

Microsoft release eScrum tool

Finally Microsoft seems to be encouraging implementation of Agile methods across its projects, and predominantly Scrum. They have gone a step ahead and have created this Scrum tool too. Read more information about this tool here. Even though this tool seems to have been created for internal project purposes, chances are their that they can commercialize it.

Right now, RallyDev, VersionOne seems to be leading the Agile PM tools bandwagon.

Performance Appraisal - Different perspective

Here is a nice quote from Ester Derby about performance appraisal:

"Performance is *not* solely a matter of individual skills. Performance is a function of the person *and* the environment. Policies, procedures, structures (and dare I say it) the quality of management all affect individual performance."

     -- Esther Derby"

What Every Manager Should Know About Feedback

Right now many companies are going through performance appraisal cycle, and the managers are supposed to give their feedback to their team members.  How should one give an effective feedback ?.  Here is a good article by Ester Derby on how to effectively give feedback to others. This article provides a clear difference between an evaluation/judegement and a feedback.  

 

Meeting Effectiveness

Recently I attended a European-Indian business summit and I was representing my company Valtech. Many Italian, Spanish companies were visiting India and were look for possible business partners.
The meeting slots were pre planned/agreed and were circulated prior to the meeting. The time slot was time boxed for 30 minutes each. Separate stalls were set up for each of the EU companies, and during the specified time slot, the representatives from the Indian firm would go to the stall and have a discussion for 30 minutes.

3 of us from Valtech, met nearly 10 companies in 2 days. An important thing I noticed in the summit was the time boxing of meetings for 30 minutes. I have never seen such an efficient meeting happening from my earlier experience. During the meetings with prospective customers, we were able to make out if this is a make or brake deal and within the first few minutes itself.

Somewhere I read that most of the decision happens within the first 15 minutes of the meeting. So, I think any meeting intended towards making some decisions, would be effective it

• it is time boxed
• lesser the time, the better
  

More info. on meeting effectiveness
In one of the Agile forums, Mark Herschberg gave the following tips to improve the meeting effectiveness:
1) Set fixed time limits. I learned this from scrum meetings where we had a
kitchen timer with 15 minutes to force everyone to be efficient. Even for
longer meetings this has been found to be effective. Even if your meetings
aren't any shorter. the act of having a timer visible on the table and
counting down helps to focus people.

2) Have an agenda. Often meetings don't have a clear agenda. Even if
people know what the meeting is for (e.g. our weekly status meeting) it can
be a bit vague and fuzzy. Every meeting should require the following:
a) These are the issues to be discussed
b) These are the questions we will have answered by the end of the meeting

3) Have a clear understanding of when questions should be discussed. Often
people get side tracked as various issues come up in meetings and people
wander down a particular thread. By knowing when and where an issue can be
discussed, it's easier to say, "that's a very good issue, why don't we
address that in X meeting which is for such topics." Everyone needs to know
what meetings there are and what each are for. I'm debating creating a
"catch all" meeting once a week at my current project so if there's anything
we miss, we can always say, "put it in the catch all meetings."

4) Build a culture of efficient. Make everyone want to have fast, efficient
meetings, and empower everyone to be able to suggest moving a topic to a
different venue,

5) Recognize that there is value in inefficiency. Fast, to the point
meetings, while generally effective, sometimes miss that creative spark that
comes from getting side tracked, from the random threads that usually are a
waste of time, but once in a while yield a great insight. (This is one of
the reasons I'm looking at a "catch all" meeting to capture some of the free
form creativity.)

DBUnit Mind Map

From the last few days I have been testing DAOs using DBUnit. During the process of learning, I created the following Mind map. I will keep updating this mind map as and when I learn something new.

Scrum Master - Picken

A discussion on scrumdevelopment forum, whether the Scrum master is chicken or Pig, lead to one of the person terming SM as "Picken", partly pig and chicken.
In fact this article provides a information about responsibilities of SM at various instances.

Agile @ Philips Innovation campus

18th May, I was invited by Philips Innovation Campus, Bangalore as a speaker to talk to their team on Agile and Scrum method. Alexius Collete, Head PIC Bangalore was present with other senior management team to be part of this session. Saran, took care of the entire coordination and provided me an excellent support for making this happen.

I could see the enthusiasm in the management team to know about Agile and how to effectively implement the same. This is a clear indication of the support for Agile implementation from the top management at PIC(top down Agile adoption strategy). There is no doubt that Agile gets nurtured in such organizations.

During the session, I was happy to see the auditorium jam packed with Agile enthusiasts. In the recent weeks, I have been invited by many companies in Bangalore !

OST and Multiplex theater

Since I learned Open Space Technology last week, I am trying to encourage my colleagues to use this as much as possible. Some new joiners have hard time understanding OST and some people get scared away by the word "Technology" in OST.

Here is an analogy(may be modified :-) ) to explain OST.

Imagine a multiplex theater running movies in parallel. These movies are based on a theme and these movies were chosen by the people who came to see the movies. You have a global ticket to watch any movie you like, any time you want . If you don't like anymovies, you can as well walk out.

Benefits of Top down Agile adoption

My article on "Benefits of top down Agile adoption strategy" has been published on Agile Journal

Good books on Agile Methods

Following Agile related books are found to be good by many readers

• Agile Project Management with Scrum - Ken Schwaber
• Agile and Iterative Development - Craig Larman
• Applying User Stories, Mike Cohn
• Agile Estimating and Planning, Mike Cohn
• Collaboration Explained, Jean Tabaka
• Lean Software Development, Mary Poppendieck
• Agile Project Management - Jim Highsmith
  
• Managing Agile Projects - Sanjiv Augustine
• Domain Driver Design: Tackling Complexity at the Heart of Software - Eric Evans
• Working Effectively with Legacy Code - Michael Feathers
• Refactoring to Patterns - Joshua Kerievsky
• Project Retrospectives: A Handbook for Team Review - Norm Kerth
• Agile Retrospectives - Ester Derby
• Fearless Change: Patterns for Introducing New Ideas, Linda Rising
• Product Development for the Lean Enterprise - Michael Kennedy
• Crystal Clear by Alistair Cockburn
• FIT for Developing Software - Rick Mugridge, Ward Cunningham

Online Resources:

• www.agilealliance. org
• www.scrumalliance. org
• www.agileadvice.com
  
• www.theagileblog. net
• www.mountaingoatsof tware.com
• www.stickyminds. com
• www.infoq.com

I will keep updating this list as and when I come across good ones..

Open Space Technology

Craig Larman conducted an Open space technology event and I had the opportunity to be part of the event. This is the first time that I participated in such an event. Open Space Technology(OST) is not really like a technology, but a way of conducting events, meetings, conferences, etc.

During OST, the session could start with a specific theme. In our case, it was about Agile methods. When the participants assembled in this huge hall, Craig requested people to come forward with a burning issue related to the theme. Volunteers(conveynors) started pouring in with their burning issues written on a post-it, and pasting the same on a specific time slot.

Once the time slots gets filled, the conveynors would go to their respective counters, and interested participants can join the discussion.

some good things that I noticed:

1. The time passed so fast that, I didn't feel that it was a meeting. Enjoyed every minute of it
2. Lot of issues came up during the event.
3. participants can get full value of such events, as they can chose the topic.
4. Pretty informal setting

Note:
This might be a premature statement, but I felt that OST may not be effective if the safety and trust of participants is not built during the session. This is especially applicable if the theme is on solving burning issues.
For ex: if the team is planning to solve some people related issues of an organization using OST, senior management team present during the session might add a fear in team's mind. The fear would be due to the repercussion for being open.

It is also quite possible that, senior management by being in authoritative position, can hijack discussions. So, good facilitation skills are needed by conveynors to handle such situations.

Usage of Tool in an Offshore Scrum Meeting

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.

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"

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,

if you don't trust your own employees, why did you hire them at the first place ?

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.

Agile Offshore Development Tip 4: Involve Offshore into Scrum meetings

I have seen distributed teams following Agile practices but each one not really sharing information with other distributed teams. For ex: Both onsite and offshore teams would be conducting Scrum meetings but skipping Scrum of Scrums.

Important thing in distributed Agile development is to include the offshore teams for all important workshops. For ex: Requirement, Retrospective, Modeling days, Iteration planning meeting.

In many onsite-offshore projects, the onsite team handles the design/architecture part and the offshore team is involved in pure development and testing. This model makes many onsite teams don't feel like involving offshore teams for Requirement workshops, modeling days.
Which in turn leads to a huge communication gap and would result in creation of a poor quality product. The above mentioned scenario would also involve lot of hand offs from onsite team to offshore team, resulting in lot of wastes being added to the system.

Systems thinking needs is the key to succeed in distributed Agile development.

TestSuites should be on Feature Themes

Many developers tend to package TestSuites to contain the tests based on technology/layers. For ex: TestSuites to contain the tests on UI layers, Dataaccess, BO.

Since we create unit tests to test a unit of functionality, the TestSuites should contain tests based on the Features/Use cases.

For Ex: TestSuites to contain Unit tests testing feature to add User Or Modify User.

Task creation for fulfilling user requrirements

At the end of the requirement workshop, first thing the Scrum team would be looking forward to is to create the tasks for the features. For the rest of the iteration, only thing they are worried is how many tasks they have been able to complete. In this process, they forget that they have to deliver the Running Testing Features(popularly known as RTF) to the customer.

One way to avoid this task creation madness could be to divide the features into smaller feature chunks that can be handled like a task. (Right now the discussion is going about this in scrumdevelopment forums)

For Ex: instead of writing a task like "Database creation", if we can rewrite it as "Database creation to fulfill the storyX" Or rewriting it as "Handling Database related work to fulfill FeatureX" could make the team to "NOT" lose their focus on features/requirements.

Applying TDD while dealing with database related actions

There are numerous thoughts about how to go about applying TDD while dealing with database access related code. Some of the common thoughts include

1. Replacing DB with Mock Objects to simulate Database
Most preferred one. Advantages include

• No need to worry about DB info, driver info,
  
• tests run faster as compared to other techniques
• No need to change any test code because you changed the database
• Easier to maintain
  

2. Using a local copy of DB
Some programmers suggest to make use of a local copy of database for testing purposes. It has its own pros and cons:

• One needs to be aware of local Database related APIs
• Keeping the local copy of DB in synch with central test DB is bit tricky, especially with a large project team.
  
• Easier to use
  

3. Use central test DB
In this case, test with the cental DB, and apply transaction/roll backs to clean up DB after the use brining the DB back to its original state

• You can be confident that your code works well with the DB
• goes against some of the unit testing principles created by thought leaders like Michael Feathers
• Easier to maintain and use
• Be aware of Database APIs, drivers, etc .

4. Use an in-memory DB (like HSQL) Or any other faster databases

Not recommended much

• Again this goes against unit testing rules
  
• easier to use
• You are not sure whether your SQL queries tried against in-memory DB works with real DB