Eye contacts in Scrum Meetings

I found this nice article by a blogger Abrachan:

When a team is transitioning from the conventional predictive project management to the adaptive style based on SCRUM method - very often it is like releasing a parrot under captivity. Suddenly the parrot gets absolute freedom and at the same time it is not conditioned to enjoy the new found freedom. It still thinks that it is under captivity. It has to strengthen the muscles required to fly in a world of unlimited freedom and opportunities to excellence.

When the daily scrum meetings happen, most of the members - if they are new to the team, still follow the reporting attitude - and keep reporting what I am supposed to do, What I did and the problems I faced - to the SCRUM master only, without any eye contact with the rest of the team. Even if the SCRUM master do not want to be seen as a command and control freak, the rest of the team still see him as a command and control freak - which is hang over from the previous predictive project management styles he/she was practising. One of the very effective tactic (fix) to de-promote this behavior by the rest of the team is to avoid the eye contact with the person who is `talking to you' in a SCRUM meeting, thus forcing him/her to look at the rest of the team members - contributing to the 'self directed team' spirit. :-)

Agile Offshore Development tip 3: 3 Key tools in Offshore development

From my experience, I found that the 3 key tools that are contributing towards improved communication in offshore development using Agile methods are:

1. Wiki (Any wiki should be fine, and we use Confluence by for the best wiki I have seen so far)

2. IMs (Skype, Yahoo, MSN)

3. IP phones (We use Cisco IP phones)

Does Agility improve design of the product ?

Like Waterfall model, Agile methods are also grouped under "process" umbrella. In fact, Agile methods are much more than this. Waterfall model provides a set of steps and guidelines on how to do software development and it has no impact on what technologies you use, and how you design or architect the software. But, Agile methods in turn has a huge impact on how you design and architect software.

In agile methods, Features are built incrementally in iterations and it is expected that the components are also built incrementally. This in turn forces the designer and architects to make conscious decisions for building modular and cohesive systems. At the same time, the less experienced designers would get entangled in their own web of coupled components and have to struggle to refactor for a longer period of time. They have no escape route !! At the same time, Big Upfront design is not the answer.

Good quote by Guru from Google

Here is a nice quote by Ram Shriram on hiring:

Hire only A people, and they’ll hire other A people. If you hire the B person, they’ll hire C or D people. Someone asked a good question: How did Shriram decide who are so-called “A” people? Grooming is a part of it. “I try to find out who their mothers are,” he said. If they are raised well, they’re more likely to make good citizens, employees and entrepreneurs.

History of Scrum

I was preparing the presentation for the new comers in my company, and thought of doing some research on history of Scrum. I found some interesting information:

1. Scrum is a variation of Sashimi

2. Sashimi originated with the Japanese and their experience with the waterfall model

3. Scrum was named as a project management style in auto and consumer product manufacturing companies by Takeuchi and Nonaka in "The new new product development game" (Harvard Business Review, Jan-Feb 1986)

4. First Documented in 1993 by Jeff Sutherland, John Scumniotales and Jeff McKenna

5. 1995: Ken Schwabber Formalized the rules for Scrum.

How XP(Xtreme Programming) got its name

I found this nice information on devx explaining how XP got its name:

XP got its name when its founders asked the question, "what would happen if we took each technique/practice and performed it to the extreme? How would that affect the software process?" An example of this is the practice of code reviews. If code reviews are good, then doing constant code reviews would be extreme; but would it be better? This led to practices such as pair programming and refactoring, which encourage the development of simple, effective designs, oriented in a way that optimizes business value.

80% of the requirements are clear, do you still need agile ?

Here is a project where the product owner has given a huge set of requirements. Let us say, X, Y and Z. He has given a time limit to the development team saying, you do whatever it takes but I want to see X,Y,Z at the end of one year. The team that has been following traditional waterfall model, decides to move towards agile methods. Inspite of knowing that the requirements wont change much, is it really necessary to follow Agile method ? Or just do whatever it takes to reach the goal ?

Before putting my thoughts on solutions, let me tell you that, this kind of model is mostly seen in product development companies, who already have an existing product and they are looking at enhancing them over a period of time with new versions.

Coming back to solutions:
1. First and foremost ensure that the estimations are in synch with the reality. It should not be that X,Y,Z takes 2 years to do it, and the product owner has given a deadline of 1 year. No matter what process you follow, this product would be a failure

2. Since, Product owner is not available for clarifications and collaboration on a day to day basis, one needs to identify a proxy who can make decisions on behalf of product owner

3. This sample case of product development can never follow all the values and principles of agile. But, they can certainly practice some of the core agile practices.

1. Daily Scrum meetings
2. Scrum of Scrums
3. Product Backlog --> Created initially by the product owner
4. Iteration Backlog --> Proxy making decisions during each iteration
5. Daily builds
6. Continuous integration
7. Usage of information radiators
8. Test Driven Development
9. Feature teams
10. Cross Functional teams
11. Team can work on Self organization
12. They even can have a scrum master
13. Pair programming
14. Usage of dual monitors
15. Velocity based estimation and/or any other estimation techniques

But remember, don't blame agile if you don't succeed in this kind of project environment, as agile methods needs customer collaboration. Without buy in from customers and stakeholders, don't expect agile methods to succeed.

Agile Offshore Development Tip 2: Keep translation time in mind during estimation

If you are working on a distributed development project with teams in countries speaking the same language(For example English, between India and US), you won't face much of problem. But if you are working in a different environment otherwise (Say, between India and Germany OR India and France, etc where they don't speak the same language), you would need to keep the language barrier in mind during estimation. (This sentence is really mouthful !!!)

For example, you might receive a requirement document in German. The customer in Germany assumes that you would do the translation to English before writing the test cases or whatever. The problem here is, the same customer also assumes that as soon as you receive the requirement document you would start the work. Which is not really so.

This is how it works: Let us say the customer hands off the requirement document on Monday, and it takes nearly 3 days to translate the same to English(or local language). (Assuming that you have an inhouse translator). Then ensure that you keep this buffer in mind while doing the estimation. Not only that, if you have a poor translator it would add much more chaos.

Testing team needs to be very cautions in this situation. Sometimes, the testing team might have to struggle for days to get the actual requirement translated to their local language, before writing the test cases. This might add undue pressure on testing team during release days.

Couple of solutions:
====================
1. Try to have as many face to face interactions and conversations as possible with the customer. Try to write the test cases based on "Drop-in meeting" principle. Basically, you can keep updating the test cases in small iterative cycle after every conversation with customer.

2. Bring the culture of using acceptance testing framework like FIT into the team.

When would agile fail ?

Following are some of the situations where agile methods would fail:

1. When Development team is interested in agile methods, and the product owner and his team is not aware of anything about agile. For example, consider an offshore project where the development team is practicing waterfall model. Suddenly one day, one of the leads feels they should move towards agile. The offshore development team start practicing some of the practices bit by bit. They would try explaining the benefits of agility to the customer, but in vain. But the team continues practicing in bits and pieces without informing PO. This would lead to failure. Basically, one needs complete support from the management, PO and other stakeholders for a successful implementation of agile methods.

2. When development team is managed by "traditional" project managers. For example, consider a situation where the development team wants to practice agile methods. If the management is not aligned with it, the team would fall apart. I have heard of a story, where the development team was practicing some of the agile practices. Due to change in project management, the new project manager with a traditional/CMM/Waterfall background started demanding the team to do more work, and started giving them deadlines to finish work. The team almost fell apart.

Ensure that the management is convinced about the benefits of agile methods.

3. Don't practice without a coach. Passion is a critical aspect to implement the practices of agile methods, but one needs to be aware of the value also. One should know the dependency of some of the agile practices. For example, practicing "just" refactoring without TDD cycle would add more problems than any benefits. In such situations, coach could add lot of value to the team

4. Don't try to implement all agile practices at once. Take one practice at a time, play with it for some time before taking on the new ones.

Practice which works in one organization may not work in the other.

Agile Offshore Development Tip 1: Estimate cautiously immediately after a release

I am planning to start a series of "Tipping" session on Agile Offshore development. I work with offshore development teams practicing agile methods day in and day out, and so I keep seeing challenges in implementing some practices.

I am taking this as an opportunity to provide some solutions(what I think as right) for these recurring problems.

Tip 1: If your team is new to agile methodology, then ensure that the iteration planning for the "new" release is done cautiously. The reason being, most of the time the estimation and planning is done based on the velocity of previous iterations. But, when you release a new version of the product to the customer, you could expect some priority defects. These "unplanned" defects needs to be fixed in the upcoming iterations. These defects might have escaped the dragnet of TDD, functional testing, etc. So, consciously take such eventuality into consideration and plan it without just relaying on previous iterations velocity.